Какое решение с точки зрения качества, более приемлемое?

[Yii2-dev]

Какое решение с точки зрения качества, более приемлемое, использовать Yii DAO или active record? Подскажите пожалуйста, никак не могу разобраться.

[ElisDN]

Вас интересует как принято в серъёзной энтерпрайз-разработке или как это сделано в Yii?

В энтерпрайзе делают чёткое разделение на пользовательский интерфейс (UI), независимую модель (Domain) и инфраструктуру в виде хранилища (Persistence) и прочих библиотек.

При этом модель - это не просто "модель", а "модель предметной области". Это не один класс, а целая система классов, коллекций, сервисов, критериев, действий, событий и прочего. Например, имеется в виду "модель агенства недвижимости" целиком.

Наследованию реализации предпочитают агрегацию, пишут полноценные объекты, вовсю используют инкапсуляцию и полиморфизм. Не используют public-поля и сеттеры. При продумывании классов ориентируются на принципы GRASP и SOLID, из контроллеров с моделью контактируют через особый сервисный слой (или шины запросов и команд). В представление возвращают не сами оригинальные сущности, а их облегчённое DTO-отображение. Пользовательский ввод принимают и валидируют отдельные классы форм, передавая потом только проверенные данные в модель.

В общем, делают всё чтобы полностью оградить оригинальные модели от прямого доступа из внешнего мира. Для каждой операции оставляя всего один (!) правильный способ, убираяя все неправильные. Это делает модель неубиваемой и каждый разработчик точно знает, что где находится. Наружу модель кидает свои события и приложение уже по ним рассылает уведоления пользователям или запускает свои побочные задачи.

Про базу при создании модели не думают вообще, делая всё абсолютно независимым от хранилища. Всё DAO и подобный фреймворковский код инкапсулируют в отдельном инфраструктурный пласт, определяемый интерфейсами в модели, чтобы это можно было легко поменять в любой момент, не меняя ни единой строчки в контроллерах и моделях. Все зависимости классов и интерфейсов удобно разрешаются и переключаются через DIC.

В жизни обычно оперируют операциями "принять на работу", "уволить", "отправить в отпуск" (а не просто "создать", "редактировать" и "удалить"). Именно такие методы запрограммированы в моделях и сервисном слое, поэтому простой CRUD здесь малоприменим, неудобен для использования и сложен работой со сценариями и валидацией, из-за чего в большинстве своём здесь считается антипаттерном.

А в Yii2 сознательно открещиваются от многих принципов и, порой, здравого смысла просто для экономии строк ради ускорения написания кода в целях RAD (всё для "скорости" и "удобства"). И любая идея мгновенно отбрасывается, если она требует от программиста хоть о чём-то подумать и может помешать бешеной скорости разработки в стиле "таблица > Gii > модель > CRUD > накидать кода в контроллер > готово".

Паттерн ActiveRecord (Активная запись) изначально - это всёго-лишь один из способов работы с базой, представляющий объектное представление строки таблицы. И всё. А в Yii2 заложен "культ ActiveRecord", где прямо из неё делают модель и форму с валидацией, жизненным циклом и завязкой на базу. Ни о какой независимости от UI, базы и фреймворка здесь не может быть и речи, так как всё собрано в одну кучу. Ещё и все поля торчат наружу, что способствует работе с AR в процедурном стиле вместо объектно-ориентированного.

Так что качество - весьма относительное понятие. И будете ли Вы использовать AR или DAO - без разницы, так как качество определяется вопросом не "что использовать", а "как и где".

[zelenin]

отметил бы, что из-за того, что в AR-модель напихано все и вся, это фейловый вариант для фронтенда серьезного продакшна. лучше вытаскивать в репозитории/сервисе голые массивы и создавать из них легкие модели (dto), не наследующие AR.
Бэкенд же не создает сильной нагрузки на проект, которую следовало бы принимать в расчет, поэтому там можно использовать все, что хочется.

[Yii2-dev]

Вас интересует как принято в серъёзной энтерпрайз-разработке или как это сделано в Yii?

В энтерпрайзе делают чёткое разделение на пользовательский интерфейс (UI), независимую модель (Domain) и инфраструктуру в виде хранилища (Persistence) и прочих библиотек.

При этом модель - это не просто "модель", а "модель предметной области". Это не один класс, а целая система классов, коллекций, сервисов, критериев, действий, событий и прочего. Например, имеется в виду "модель агенства недвижимости" целиком.

Наследованию реализации предпочитают агрегацию, пишут полноценные объекты, вовсю используют инкапсуляцию и полиморфизм. Не используют public-поля и сеттеры. При продумывании классов ориентируются на принципы GRASP и SOLID, из контроллеров с моделью контактируют через особый сервисный слой (или шины запросов и команд). В представление возвращают не сами оригинальные сущности, а их облегчённое DTO-отображение. Пользовательский ввод принимают и валидируют отдельные классы форм, передавая потом только проверенные данные в модель.

В общем, делают всё чтобы полностью оградить оригинальные модели от прямого доступа из внешнего мира. Для каждой операции оставляя всего один (!) правильный способ, убираяя все неправильные. Это делает модель неубиваемой и каждый разработчик точно знает, что где находится. Наружу модель кидает свои события и приложение уже по ним рассылает уведоления пользователям или запускает свои побочные задачи.

Про базу при создании модели не думают вообще, делая всё абсолютно независимым от хранилища. Всё DAO и подобный фреймворковский код инкапсулируют в отдельном инфраструктурный пласт, определяемый интерфейсами в модели, чтобы это можно было легко поменять в любой момент, не меняя ни единой строчки в контроллерах и моделях. Все зависимости классов и интерфейсов удобно разрешаются и переключаются через DIC.

В жизни обычно оперируют операциями "принять на работу", "уволить", "отправить в отпуск" (а не просто "создать", "редактировать" и "удалить"). Именно такие методы запрограммированы в моделях и сервисном слое, поэтому простой CRUD здесь малоприменим, неудобен для использования и сложен работой со сценариями и валидацией, из-за чего в большинстве своём здесь считается антипаттерном.

А в Yii2 сознательно открещиваются от многих принципов и, порой, здравого смысла просто для экономии строк ради ускорения написания кода в целях RAD (всё для "скорости" и "удобства"). И любая идея мгновенно отбрасывается, если она требует от программиста хоть о чём-то подумать и может помешать бешеной скорости разработки в стиле "таблица > Gii > модель > CRUD > накидать кода в контроллер > готово".

Паттерн ActiveRecord (Активная запись) изначально - это всёго-лишь один из способов работы с базой, представляющий объектное представление строки таблицы. И всё. А в Yii2 заложен "культ ActiveRecord", где прямо из неё делают модель и форму с валидацией, жизненным циклом и завязкой на базу. Ни о какой независимости от UI, базы и фреймворка здесь не может быть и речи, так как всё собрано в одну кучу. Ещё и все поля торчат наружу, что способствует работе с AR в процедурном стиле вместо объектно-ориентированного.

Так что качество - весьма относительное понятие. И будете ли Вы использовать AR или DAO - без разницы, так как качество определяется вопросом не "что использовать", а "как и где".

Большое спасибо, за профессиональный и качественный ответ. Да-да, интересует именно качество,а "как и где" рекомендуете использовать?

[ElisDN]

Большое спасибо, за профессиональный и качественный ответ.

Оставьте одно предложение в цитате, чтобы всю простыню не дублировать

Да-да, интересует именно качество, а "как и где" рекомендуете использовать?

Общая рекомендация - не использовать ничего напрямую в контроллере. Один из шагов - вынесение в сервисы, если хотите хоть как-то тестировать код. А так архитектура - это уже отдельный этап со своей кучей литературы. Первым делом нужно начать с понимания самого ООП и его принципов, а потом, если будет интересно, двигаться дальше.

[AlexG]

Было бы интересно посмотреть на какой нить энтерпрайз проект на yii. Интересно есть такие в опенсорсе?

[sda]

ElisDN, а вы бы могли в будущем вебинар на эту тему провести? Что и куда класть, чтобы бизнес логика была обычным POPO ни от чего не зависящая и ни от кого не наследующаяся.

[ElisDN]

ElisDN, а вы бы могли в будущем вебинар на эту тему провести? Что и куда класть, чтобы бизнес логика была обычным POPO ни от чего не зависящая и ни от кого не наследующаяся.

Вебинара не хватит

Начните с https://habrahabr.ru/post/267125/

Перечитайте обсуждения:

viewtopic.php?f=28&t=31100
viewtopic.php?f=4&t=34862
viewtopic.php?f=4&t=35310
viewtopic.php?f=12&t=33304
viewtopic.php?f=12&t=17784
viewtopic.php?f=26&t=34859

Потом подбирайтесь к статьям и книгам:

viewtopic.php?f=19&t=34472&p=175536#p175531
http://sergeyteplyakov.blogspot.ru/2014 ... iples.html
http://sergeyteplyakov.blogspot.ru/2014 ... d-ood.html
https://megamozg.ru/post/6824/
http://martinfowler.com/books/eaa.html читать только на английском
http://www.ozon.ru/context/detail/id/30958003/
http://www.amazon.com/Applying-Domain-D ... 0321268202

Почитайте и просмотрите ещё пару месяцев выдачу гугла и ютуба по каждому термину и аббревиатуре. Тогда некое понимание придёт.

Как-то так...

[sda]

ElisDN, ну я знаком с solid, grasp, с некоторыми шаблонами проектирования. Читал книгу Head First Disign Patterns, смотрел курс по паттернам от Сергея Немчинского. Читал эту статью про гексогональную архитектуру и некоторые перечисленные топики с этого форума тоже. Я понимаю некоторые проблемы, замечаю их в коде, вижу зависимости кода от фреймворка. Но я также видел какой-то пример реализации ddd, помню что там было множество классов, в каждом методе которого по 1-2 строчки кода и это (для меня) не выглядело чем-то более понятным и логичным, чем-то что проще поддерживать, скорее наоборот, усложнением из-за нагромождения огромного количества сущностей друг на друга. Я даже не понял, какую бизнес задачу это решало, складывалось впечатление, что никакую.

Должна наверное быть некая золотая середина. В мире помоему нет ничего идеального. И вот хотелось бы от вас узнать в форме вебинара как найти эту золотую середину, какие плюсы/минусы здесь, какие там. Пример связанного кода на Yii2 и развязанного кода на Symfony 2. Ну или как угодно. Зачем вообще писать развязанный и не зависящий код от фреймворка. Что это дает с прагматической точки зрения. Это хотелось бы услышать.

Просто некоторые товарищи пишут, что для сложного проекта им то Active Record мешает, то еще что и вообще Yii фигня, так как подталкивает к написанию связанного кода. И складывается впечатление, что вокруг тебя одни сеньоры со сложными проектами, а ты дно. Но почему-то, когда я вижу эти "сложные проекты" то там костыль на костыле, классы по 5 тыс. строк и методы по 1 тыс. строк и никто там не знает как и что вообще работает. Не видел я там никогда ни каких слабосвязанных архитектур или каких-то ddd. Я там вообще никаких архитектур не видел. Это просто как-то работет и приносит владельцам доход. А рабы латают дыры. Вот что я видел.

[zelenin]

Но я также видел какой-то пример реализации ddd, помню что там было множество классов, в каждом методе которого по 1-2 строчки кода и это (для меня) не выглядело чем-то более понятным и логичным, чем-то что проще поддерживать, скорее наоборот, усложнением из-за нагромождения огромного количества сущностей друг на друга

маленькие классы - следствие S из SOLID. Это классы, решающие базовую, атомарную задачу. Из этого два следствия: а) больше классов, в которых на первый взгляд труднее разобраться (с другой стороны мы программируем интерфейсами, что облегчает вам поиск зависимостей в ИДЕ и помогает прогить) и б) вы моментально рефакторите эти самые зависимости (опять же потому что атомарные методы и программирование интерфейсами). Это все абстрактно пока сам не попробуешь и не поймешь.

Собственно сам был свидетелем, когда стояла задача внести большое изменение в работу крупного сайта, человек трудился пару недель, продумывал как и куда вкорячить хак, общался с тим лидом и в итоге было решено задачу заморозить, поскольку она была небезопасна, с трудно отслеживаемыми возможными багами. Что к этому привело? Отсутствие прослойки над AR. И когда тебе на совет юзать сервисный слой или репозитории, отвечают дескать зачем мне вводить еще одну сущность, если я могу напрямую в экшне сделать Goods::find()->all(), я смеюсь в усы - когда у тебя этот Goods::find() будет в 1000+ мест, что-то менять уже будет поздно (особенно когда, к тебе через неделю подойдут и скажут, сколько компания потеряла из-за того, что ты забыл хак применить при генерации отчетов о комиссии).

Просто некоторые товарищи пишут, что для сложного проекта им то Active Record мешает, то еще что и вообще Yii фигня

Минусы и плюсы AR очевидны и во многом совпадают с минусами и плюсами yii. Очень быстро разрабатывать, очень трудно поддерживать при развитии проекта. А AR для крупного проекта еще и просто очень тяжел.

Но почему-то, когда я вижу эти "сложные проекты" то там костыль на костыле, классы по 5 тыс. строк и методы по 1 тыс. строк и никто там не знает как и что вообще работает.

в таком описании я вижу типичный проект на yii, написанный так называемой лапшой без выделения ответственностей. Это когда тебя спрашивают "как лучше сделать", а ты отвечаешь "в контроллере" или "создай статический метод в модели", то через полгода твои классы по 5т строк.

Кстати, что характерно: вначале вы не одобрили вынос функционала в разные классы, теперь не одобряете лапшу в одном классе.

Не видел я там никогда ни каких слабосвязанных архитектур или каких-то ddd. Я там вообще никаких архитектур не видел. Это просто как-то работет и приносит владельцам доход. А рабы латают дыры. Вот что я видел.

о том и речь: вы в сообществе yii никогда не увидите подобного кода. YIi о скорости разработки, а не об архитектуре и качестве.

PS пометка для людей, страдающих проблемами экстраполяции: когда я говорю "нет" и "никогда" это значит, что что-то статистически незначимо и близко к нулю, а, значит, вероятно нет, чем да.

[sda]

Кстати, что характерно: вначале вы не одобрили вынос функционала в разные классы, теперь не одобряете лапшу в одном классе

Ну да, потому что я хотел бы найти для себя золотую середину. Допустимый уровень технического долга. Я не хочу претендовать на звание академика ооп. Я просто хочу писать более менее приличный код, не слишком заумный, но и не совсем лапшу.

[zelenin]

Кстати, что характерно: вначале вы не одобрили вынос функционала в разные классы, теперь не одобряете лапшу в одном классе

Ну да, потому что я хотел бы найти для себя золотую середину. Допустимый уровень технического долга. Я не хочу претендовать на звание академика ооп. Я просто хочу писать более менее приличный код, не слишком заумный, но и не совсем лапшу.

здраво. начните с сервисного слоя и интерфейсов.

[ElisDN]

Но я также видел какой-то пример реализации ddd, помню что там было множество классов...

Уже два месяца читаю залпом английскую выдачу гугла и рассматриваю все примеры. Есть достойные, есть не очень. Так что на какой попадёте.

Зачем вообще писать развязанный и не зависящий код от фреймворка. Что это дает с прагматической точки зрения. Это хотелось бы услышать.

Ключевой профит с точки зрения удобства - позволяет абсолютно свободно программировать именно логику на чистом ООП, как угодно вкладывая классы друг в друга и как угодно называя поля. Без любых ограничений.

Не отвлекаясь и не думая вообще о базах, контроллерах и прочем техническом геморрое. Без многодневных рыданий вроде "как же мне в поле ActiveRecord массив записать".

Можно сначала всё ядро системы спрограммировать и в консоли и в тестах запускать для проверки. А потом уже когда-нибудь фреймворк с базой привязать. Хоть MySQL, хоть MongoDB, хоть XML-файлы. Хоть обе базы сразу: чтобы записывалось в одну, а читалось из другой. Можно будет на разных базах или фреймворках погонять и скорость потестить.

Отвязка от фреймворка позволяет запускать и тестировать код без этого фреймворка. Отвязка от базы даёт возможность легко переключать эти базы, если что-то стало тормозить. Для тестов пишем репозиторий с сохранением в массив в приватном поле вместо записи в базу, и сотни тестов запускаются за 20 миллисекунд. А ещё можно целиком поменять весь фреймворк или любую библиотеку. Или, скажем, поднять инстанс на Joomla, Wordpress или Bitrix, написав маленький плагин-обёртку над этим же кодом и подгрузив в vendor какой-нибудь DI контейнер.

Код, написанный на простом PHP работает везде, а код, написанный на Yii - только на Yii.

Просто некоторые товарищи пишут, что для сложного проекта им то Active Record мешает, то еще что и вообще Yii фигня, так как подталкивает к написанию связанного кода... Но почему-то, когда я вижу эти "сложные проекты" то там костыль на костыле, классы по 5 тыс. строк и методы по 1 тыс. строк и никто там не знает как и что вообще работает.

У одних "Active Record мешает", у других "там костыль на костыле, классы по 5 тыс". Это разные товарищи. Не путайте их.

Не видел я там никогда ни каких слабосвязанных архитектур или каких-то ddd. Я там вообще никаких архитектур не видел. Это просто как-то работет и приносит владельцам доход. А рабы латают дыры. Вот что я видел.

А от кого Вы хотите мега-архитектуру увидеть? От авторов 499 тем про установку самого лёгкого любительского фреймворка, идущих работать такими рабами? И ваши знакомые бизнесмены очень сильно ищут дорогих и крутых архитекторов?

[sda]

А от кого Вы хотите мега-архитектуру увидеть? От авторов 499 тем про установку самого лёгкого любительского фреймворка, идущих работать такими рабами? И ваши знакомые бизнесмены очень сильно ищут дорогих и крутых архитекторов?

Ну я не только yii имел ввиду. В целом индустрию веба. Помоему большинство всех популярных проектов это обычная процедурная лапша, вообще без каких-либо фреймворков и архитектур.

Например я видел оригинальные исходники некоторых действующих проектов от майл.ру и там была процедурная лапша, прям вот вообще html + php всё в перемешку, никаких mvc. Еще я видел много разных cms на php и везде тоже была процедурная лапша. Они все такие красивые снаружи, все такие динамичные, но открываешь код, а там https://github.com/PrestaShop/PrestaSho ... s/Cart.php без 18% 5 тыс. строк.
И это популярная екоммерс система у которой штат разработчиков более 100 человек. Ну а еще вконтакте, фейсбук, твиттер и всё остальное наверняка выглядит примерно также, если не хуже. На тостере программист рассказывал, как он работал в мвидео и какое это вообще адское говно.

То есть я не знаю ни одного работающего проекта, где есть какая-то крутая архитектура, где чтут grap, solid и молятся на Фаулера. Я вижу совсем другую картину. Вот я и не знаю от кого можно увидеть эту мега-архитектуру. Мне кажется, что меня вводят в заблуждение, что нужно писать круто, затем нужно писать еще круче, чем писал, и еще, и еще. В итоге я уже несколько лет не могу дописать свой высер, потому что собираю все эти принципы и правила и пытаюсь им следовать. Этот высер сменил уже 2 фреймворка, как я понимаю, сейчас мне нужно сменить его еще раз, ведь я всё еще мать его не достаточно крут. И от этого всего опускаются руки, так как все вокруг твердят, что ты пишешь говно и вообще ты лох.

[ElisDN]

Ну я не только yii имел ввиду. В целом индустрию веба. Помоему большинство всех популярных проектов это обычная процедурная лапша, вообще без каких-либо фреймворков и архитектур.

Ну не все сразу что-то умное читают. И в школе этому не учат. Да и у пэхапешников учиться особо не принято. Многие по пять лет на процедурных CMS-ках сидят, а потом вдруг с классами, пространствами имён и композером первый раз в жизни сталкиваются только сейчас во фреймворке. У всего есть причина.

процедурная лапша, прям вот вообще html + php всё в перемешку, никаких mvc... И это популярная екоммерс система у которой штат разработчиков более 100 человек... как он работал в мвидео и какое это вообще адское говно.

Почти все CMS чуть ли не с в лихих девяностых и нулевых с PHP4, когда даже фреймворков-то не было. Вот и тянется в PrestaShop лапшекод с синглтонами из 2007-го. Тогда и интернет по диал-апу был и компьютеры не у всех имелись.

То есть я не знаю ни одного работающего проекта, где есть какая-то крутая архитектура, где чтут grap, solid и молятся на Фаулера. Я вижу совсем другую картину. Вот я и не знаю от кого можно увидеть эту мега-архитектуру.

Ну, как видите, только в свежих стартапах об этом думают. А в Java и .NET архитектуру с пелёнок прививают. Там пока студию установишь борода отрастёт.

А так https://habrahabr.ru/company/2gis/blog/130162/
Остальное на Symfony.

[yan]

..
То есть я не знаю ни одного работающего проекта, где есть какая-то крутая архитектура, где чтут grap, solid и молятся на Фаулера. Я вижу совсем другую картину. Вот я и не знаю от кого можно увидеть эту мега-архитектуру. Мне кажется, что меня вводят в заблуждение, что нужно писать круто, затем нужно писать еще круче, чем писал, и еще, и еще...

Причина проста - требования бизнеса, как бы там круто не хотели-умели программировать разработчики, сложные-неожиданные-срочные изменения вносимые в проект часто ломают месяцами, а то и годами построенную архитектуру. Да есть красивое модное слово - тех. долг, да есть даже у некоторых руководителей понимание, что его надо отдавать и на это надо выделять время, но по факту все равно тех. долг копится, в том числе потому, что сделать какой-то значительный рефакторинг в активно развивающемся проекте с кучей разработчиков вещь проблематичная и постепенно тех. долг становится тех. фактом то бишь легаси кодом так и получается всякая лажа даже если большинство разработчиков опытные и хотят делать хорошо. Поэтому наверное совсем красиво делаются только проекты которые делаются неспешно, без жесткого давления бизнеса, но это в основном опенсорсные проекты, всякий for fun.
Единственный принцип который из этого всего для себя вынес - необходимо делать максимально хорошо, плохо само получится Чем изначально правильней сделаешь архитектуру и чем больше будешь стараться следовать ей в дальнейшем, тем меньше будет проблем, даже если придется костылить.

.. В итоге я уже несколько лет не могу дописать свой высер, потому что собираю все эти принципы и правила и пытаюсь им следовать. Этот высер сменил уже 2 фреймворка, как я понимаю, сейчас мне нужно сменить его еще раз, ведь я всё еще мать его не достаточно крут. И от этого всего опускаются руки, так как все вокруг твердят, что ты пишешь говно и вообще ты лох.

Совершенствоваться можно бесконечно, если не стоять на месте, то многое из того, что ты делал несколько лет назад будет казаться абсолютным г., это хорошо, это значит есть прогресс.

[pgamaster]

Извините за ап старой темы.
Я пока не увидел в работе фреймворк на Java - Spring boot то думал что yii манна небесная. Просто посмотрите как строится архитектура там, многое прояснится.
Yii хорош для простого CRUD приложения и быстрой разработки, за это ему спасибо. Нравится что можно быстро сваять ajax таблички и уже работать с ними.