Кирилл Горлов: не, я к тому что при таком подходе это надо проверять дважды, на клиенте (для лучшего UX) и на сервере (что бы недай боже какая ... послала невалидные данные).
В любом случае это уже не столь важно в контексте вопроса.
Кирилл Горлов: обычно то что вы описываете целиком делается на сервере, а в ангуляре рекомендую завести привычку делать сервисы-репозитории которые работают с сервером и только они знают как чего куда посылать.
Кирилл Горлов: по сути это то что вы и делаете, только ваш вариант (если я правильно понимаю) делает неявную зависимость директивы от места применения.
а в директиве через изоляцию скоупа пробросить это как колбэк (смотреть документацию по директивам, а именно изолированный скоуп и символ амперсанта (&))
vasIvas: статья интересная, но опять же, причем тут MVC? MVC регламентирует как следует строить взаимодействие между приложением и интерфейсом, и не более. То есть модель в контексте MVC это ооочень обобщенное понятие. Вся идея MVC заключается во введении медиатора между двумя слоями дабы устранить зависимость одного от другого.
vasIvas: я это к тому что MVC не регламентирует что у вас там и как за контроллером, оно регламентирует как должен происходить процесс интерактивного взаимодействия пользователя (через слой представления) и модели через промежуточный медиатор - контроллер.
А ссылку на статью все ж дайте, любопытно что вас там смутило, может сам начну сомневаться)
vasIvas: и да и нет. Модель предметной области это частный случай скорее. В MVC (олдскульном) модель (фр. modèle, от лат. modulus — «мера, аналог, образец») это просто какое-то состояние ваших данных, вы можете совершать над моделью действия и в ответ она будет менять свое состояние.
OnYourLips: 1) ну с 2.2 вообще был кошмар, даже если брать 2.4 версию то там уже все намного лучше, 2.5 вообще сказка. Последние года так полтора я особо проблем с доктриной не ловлю и не наблюдаю торчащего DBAL. Есть правда свои нюансы, скажем пользоваться доктриной на mysql боль и унижение. А вот с постгресом все просто работает.
2) немного не понял, причем тут бандлы и ar? Я к слову никогда не понимал идеи разделять приложение на бандлы и в последнее время вообще отказался от оных (в рамках приложения, сторонние использую). Я не работал с eloquent, только пробовал, и не могу ничего сказать. Но если брать как пример Yii2 - там модели использовать как бизнес сущности, не как анемичную модель невозможно и просто опасно, могут быть тонны побочных эффектов. Хотя все можно делать, я видел как чуваки пытаются практиковать DDD с eloquent, но мне показалось это менее удобным чем с доктриной.
Доктрина за последние три года хорошо так подросла. Там есть еще свои проблемы, но с момента перехода на postgresql я вообще перестал испытывать проблемы с ней.
Александр: работаю с симфони более трех лет, количество готовых решений конечно впечатляет, но качетсвенных кот наплакал. Я обычно сильно расстраиваюсь когда вижу очередной бандл. Да что далеко ходить - нормального бандла для аплоада файлов нету, приходится использовать всякие vich uploader. В остальном да.
Александр N++: ну а не должно быть, доктрина это гарантирует. Если у foo и bar связь с одним и тем же пользователем, то и объекты это должны быть одни и те же. То есть значение foo->user и bar->user будут ссылаться на один и тот же инстанс юзера. Это то что должна гарантировать нормальная ORM.
OnYourLips:
1) я не пишу геттеры/сеттеры, вообще это тип антипаттерн (хотя до 2.5 в доктрине по другому было сложно), зато у сущностей все хорошо с принципом открытости/закрытости ну и не забываем что есть такая штука как инкапсуляция.
2) у меня нет сервисов отдельных, 90% логичи реализуется прямо в сущностях (оставшиеся 10% случаев выносятся в сервисы только потому что иначе сущности начинают знать что-то совсем не относящееся к ним ну и репозиторий еще, но там все выборки и все такое в любом случае и вообще все что связано с доктриной)
3) вы не учитываете что вам надо все же базу данных иметь, то есть нет конфигов это круто, но для того что бы это было реальностью вам надо сначала сделать схему базы данных. У меня же главное это бизнес объекты и их взаимодействие, а структура базы формируется автоматом по этим самым конфигам описывающим связи объектов. С AR же мы в любом случае сначала должны спроектировать базу данных.
4) я не валидирую модель (хотя это сомнительный довод, в Laravel тоже так можно) так как она не может войти в невалидное состояние
5) доктрина позволяет строить бизнес логику сразу, максимально быстро и максимально удобно. Если логика простая (CRUD обычный) то да, эти преимущества довольно сомнительны. Но бывают довольно сложные фичи и такой подход позволяет быстрее найти сценарии которые небыли покрыты на плэнингах/грумингах.
6) за счет identity map (я не уверен к слову, в eloquent есть оно?) я могу спокойно работать с бизнес объектами и не беспокоиться на счет дублирования
7) за счет unit of work я могу не париться из-за сохранения, мне не нужно дергать save методы или вручную коммитить транзакции, все ресолвится на уровне инфраструктуры и я просто работаю с бизнес объектами. Соблюдается принцип persistence ignorance.
То есть доктрина (при наличии опыта работы с оной) может увеличивать стоимость разработки только за счет того что в среднем разработчики использующие доктрину дороже. Время разработки будет примерно тем же, но качество решений может быть выше. Опять же все это имеет смысл только в случае если мы имеем дело с бизнес логикой сложнее блога, что-то типа каталога товаров скорее.
OnYourLips: в целом же соглашусь - в большинстве проектов доктрина может будет лишней, с другой стороны это тоже своего рода плюс, так как проектов на symfony+doctrine много, и они судя по этой логике должны быть интереснее.
OnYourLips: и да, я могу совершенно спокойно покрывать бизнес логику в сущностях юнит тестами, с active record же насколько я понимаю это невозможно, только интеграционные.
