Разделение приложения на слои

[zelenin]

Да, вот так вот делать не стоит - class ArticleRepository extends Article
Каюсь, сам так делал .... Отгрёб проблем со связями и сценариями. Article - должна быть одна и не наследуемая. Надуманный минус " Наследуемся от Article (ActiveRecord), чтобы избежать перечисления всех нужных свойств" не такой уж и страшный, по сравнению с трудностями, с которыми можно столкнуться при наследовании.
Даже вот в gii уже есть идея переделать генерацию формы поиска - https://github.com/yiisoft/yii2-gii/pull/61

Я вас услышал, а можно пример, где могут быть проблемы ?

ну есть понимание, что это просто неправильно? Если вы наследуете ArticleRepository extends Article, то ArticleRepository - это модель AR с добавленными методами. Тогда уж пишите сразу в Article.

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

У меня таки складывается впечатления, что вы таки не очень таки любите yii2 в последнее время. Но все-же еще часть сообщества, расскажите вашу историю подробнее, мне интересно.

с yii было удобно начинать два года назад (низкий порог входа). Но с ростом опыта приходит желание сделать правильно и чувство прекрасного, хороший вкус итд - как хотите назовите. Становится очевидным, что yii2 - это вообще из другой оперы.

если хочется на yii, то имхо нужно принять "правила игры", т.к. внутри yii все сильно связано, и чтобы ты ни делал - это тупо надстройка над старым функционалом. Бредово все это выглядит при реализации. Думаю, если хочется совершенствования надо мигрировать на более правильные продукты. В yii ничего не хотят менять в этом плане. В то время, как мир php пищит от принятия psr-7, развязывающего руки в выборе инструментов, разработчик yii2 заливает новый велосипед без поддержки стандарта (https://github.com/yiisoft/yii2-httpclient) - дичь какая-то. PSR-3 опять же не собираются внедрять. В общем такие дела)

Значит у разработчиков есть какие-то причины по этому поводу.

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

Давайте по делу - я не хочу на форуме yii рассказывать какой yii плохой.

[nepster]

Да, вот так вот делать не стоит - class ArticleRepository extends Article
Каюсь, сам так делал .... Отгрёб проблем со связями и сценариями. Article - должна быть одна и не наследуемая. Надуманный минус " Наследуемся от Article (ActiveRecord), чтобы избежать перечисления всех нужных свойств" не такой уж и страшный, по сравнению с трудностями, с которыми можно столкнуться при наследовании.
Даже вот в gii уже есть идея переделать генерацию формы поиска - https://github.com/yiisoft/yii2-gii/pull/61

Я вас услышал, а можно пример, где могут быть проблемы ?

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

У меня таки складывается впечатления, что вы таки не очень таки любите yii2 в последнее время. Но все-же Вы еще часть сообщества, расскажите вашу историю подробнее, мне интересно.

если хочется на yii, то имхо нужно принять "правила игры", т.к. внутри yii все сильно связано, и чтобы ты ни делал - это тупо надстройка над старым функционалом. Бредово все это выглядит при реализации. Думаю, если хочется совершенствования надо мигрировать на более правильные продукты. В yii ничего не хотят менять в этом плане. В то время, как мир php пищит от принятия psr-7, развязывающего руки в выборе инструментов, разработчик yii2 заливает новый велосипед без поддержки стандарта (https://github.com/yiisoft/yii2-httpclient) - дичь какая-то. PSR-3 опять же не собираются внедрять. В общем такие дела)

Значит у разработчиков есть какие-то причины по этому поводу.

Я думаю на любом языке программирования и на любом framevork`e можно написать как хороший код так и плохой код. При этом framevork это только инструмент и его можно использовать по разному.

Я имею ввиду, что в симфони2, что в зенде 2, что в yii2 есть сеньеры/инженеры, которые занимаются архитектурными решениями, и если если кто-то что-то не поддерживает, это не значит, что например на yii2 нельзя писать большие проекты, просто другой подход.

Кстате вы зря думаете, что не нужно писать плохое про yii на форуме yii, тогда как по вашему разработчики прислушаются к мнениям ? =)

В общем я вас услышал, подпилю и выложу следующую версию.

[zelenin]

Я думаю на любом языке программирования и на любом framevork`e можно написать как хороший код так и плохой код. При этом framevork это только инструмент и его можно использовать по разному.

все верно. только yii2 - жестко связанный продукт, а, значит, навязывает свою внутренню архитектуру.

Я имею ввиду, что в симфони2, что в зенде 2, что в yii2 есть сеньеры/инженеры,

я это читаю как: Я имею в виду, что в МЭИ, что в МАИ, что в первом классе школы, есть хорошие инженеры.

Кстате вы зря думаете, что не нужно писать плохое про yii на форуме yii, тогда как по вашему разработчики прислушаются к мнениям ? =)

никак не прислушаются. viewtopic.php?f=27&t=31259 показательная ветка, где один из разработчиков фреймворка рассуждает об удобстве, а не правильности. Я ведь тщательно слежу за разработкой два года - знаю, какого рода аргументация применяется для обоснования решений.

[nepster]

Я думаю на любом языке программирования и на любом framevork`e можно написать как хороший код так и плохой код. При этом framevork это только инструмент и его можно использовать по разному.

все верно. только yii2 - жестко связанный продукт, а, значит, навязывает свою внутренню архитектуру.

Я имею ввиду, что в симфони2, что в зенде 2, что в yii2 есть сеньеры/инженеры,

я это читаю как: Я имею в виду, что в МЭИ, что в МАИ, что в первом классе школы, есть хорошие инженеры.

Кстате вы зря думаете, что не нужно писать плохое про yii на форуме yii, тогда как по вашему разработчики прислушаются к мнениям ? =)

никак не прислушаются. viewtopic.php?f=27&t=31259 показательная ветка, где один из разработчиков фреймворка рассуждает об удобстве, а не правильности. Я ведь тщательно слежу за разработкой два года - знаю, какого рода аргументация применяется для обоснования решений.

И что вы предлагаете ? Ну начнем с вопроса, в сторону какого продукта вы посматриваете ?

[zelenin]

Я думаю на любом языке программирования и на любом framevork`e можно написать как хороший код так и плохой код. При этом framevork это только инструмент и его можно использовать по разному.

все верно. только yii2 - жестко связанный продукт, а, значит, навязывает свою внутренню архитектуру.

Я имею ввиду, что в симфони2, что в зенде 2, что в yii2 есть сеньеры/инженеры,

я это читаю как: Я имею в виду, что в МЭИ, что в МАИ, что в первом классе школы, есть хорошие инженеры.

Кстате вы зря думаете, что не нужно писать плохое про yii на форуме yii, тогда как по вашему разработчики прислушаются к мнениям ? =)

никак не прислушаются. viewtopic.php?f=27&t=31259 показательная ветка, где один из разработчиков фреймворка рассуждает об удобстве, а не правильности. Я ведь тщательно слежу за разработкой два года - знаю, какого рода аргументация применяется для обоснования решений.

И что вы предлагаете ? Ну начнем с вопроса, в сторону какого продукта вы посматриваете ?

я ничего не предлагаю. я комментирую вашу структуру с учетом своего видения.

[nepster]

Ну все я тогда завтра попробую представить новую с вашими рекомендациями (за них отдельное спасибо).

Ну а если по секрету, в сторону другого продукта посматриваете ?

[zelenin]

Ну все я тогда завтра попробую представить новую с вашими рекомендациями (за них отдельное спасибо).

Ну а если по секрету, в сторону другого продукта посматриваете ?

в сторону слабо связанных компонентов.

[samdark]

- http://auraphp.com/
- http://symfony.com/components
- https://packages.zendframework.com/

и т.д.

[nepster]

Ну все я тогда завтра попробую представить новую с вашими рекомендациями (за них отдельное спасибо).

Ну а если по секрету, в сторону другого продукта посматриваете ?

в сторону слабо связанных компонентов.

Это понятно, я тоже таким пытаюсь увлекаться, но я имею ввиду более конкретное что-то, например зенд или еще что-то ?

[zelenin]

- http://auraphp.com/
- http://symfony.com/components
- https://packages.zendframework.com/

и т.д.

да, все верно. При понимании изнутри работы например yii2 ничто не мешает из роутера, http-компонента, di, шаблона собрать что-то свое, на которое обсуждаемая здесь структура ляжет как влитая.

[nepster]

- http://auraphp.com/
- http://symfony.com/components
- https://packages.zendframework.com/

и т.д.

Александр, а вы не хотите прокомментировать более подробно слоистую архитектуру в yii2 или может что-то добавить от себя по теме ?

[zelenin]

Ну все я тогда завтра попробую представить новую с вашими рекомендациями (за них отдельное спасибо).

Ну а если по секрету, в сторону другого продукта посматриваете ?

в сторону слабо связанных компонентов.

Это понятно, я тоже таким пытаюсь увлекаться, но я имею ввиду более конкретное что-то, например зенд или еще что-то ?

смотри: есть yii2, где все жестко связано. Есть симфони - готовый фреймворк на основе симфони-компонентов с готовой обвязкой в виде конфигурации итд. А есть любое твое решение, собранное на базе симфони- и других компонентов.

[zelenin]

тот же ларавел например - это yii2 на основе симфони-компонентов. Имхо.

[samdark]

nepster, задавайте конкретные вопросы, отвечу.

[nepster]

nepster, задавайте конкретные вопросы, отвечу.

zelenin выше упоминал, что разработчики yii2 не особо прислушиваются к сообществу. Что касается большой связанности почему ее не разделяют (валидация и фильтры это конечно такое, основной вопрос именно по слоистой архитектуре) ?

[samdark]

разработчики yii2 не особо прислушиваются к сообществу

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

Что касается большой связанности почему ее не разделяют (валидация и фильтры это конечно такое, основной вопрос именно по слоистой архитектуре) ?

Не очень понял вопрос. Почему из Yii не выделены отдельные компоненты?

[nepster]

разработчики yii2 не особо прислушиваются к сообществу

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

Что касается большой связанности почему ее не разделяют (валидация и фильтры это конечно такое, основной вопрос именно по слоистой архитектуре) ?

Не очень понял вопрос. Почему из Yii не выделены отдельные компоненты?

По первому моменту я вас понял и услышал. Спасибо.

Что касается отдельных компонентов, нет я имею ввиду то, что обсуждается в этой теме. Тоесть сейчас у нас есть такой божественный класс (это модель yii), который делает все. Если 20 человек из сообщества еще делают FormModel, Model, ModelSearch, это здорово. Но нет именно слоистой архитектуры, тоесть тот же паттер репозиторий, yii2 прощает многое, потом получается очень много божественных классов (моделей).


Александр, еще такой вопрос. Если бы я к вам пришел с вопросом создания высоконагруженной социальной сети (классический пример).
Предоставил бы бюджет в пол миллиона долларов (утрирую) и оставил бы выбор технологий за вами (в рамках фантазии основная технология php). Вы бы выбрали yii2 ?

[samdark]

Слоёность со старта не имеет смысла в слишком многих случаях, чтобы её форсировать. Всё-таки много всего, что делается под веб — оно довольно простое. Поэтому Yii не пытается мешать писать совершенно тупой (прямолинейный, без абстракций) код. Этот код не плох. Он прост и понятен даже новичку. Это его плюс. Минусы его проявляются когда проект выстреливает и надо развиваться. Код начинает дублироваться, одни части ломают другие и т.д. В этом случае исхода два:

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

Можно и сразу наслоить. Как плюс получим какую-никакую гибкость на тему изменений. Как минус — запросто можно увлечься и переусложнить. Ну и без постоянного рефакторинга слоёный код скатывается в попахивающее месиво также, как и слоёный.

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

[samdark]

Александр, еще такой вопрос. Если бы я к вам пришел с вопросом создания высоконагруженной социальной сети (классический пример).
Предоставил бы бюджет в пол миллиона долларов (утрирую) и оставил бы выбор технологий за вами (в рамках фантазии основная технология php). Вы бы выбрали yii2 ?

Вообще это отношения к теме слоёности не имеет, но ответ — да. Хотя использовал бы не только его. В том же Stay.com нагрузки уже можно назвать высокими и нам пришлось отдельные вещи реализовать не на PHP или отдать на обработку внешним сервисам.

[xoma]

Свои 5 копеек по приведенному примеру кода:

1 Избавьтесь от $model = new ArticleForm(); и особенно $service = new ArticleService(); в контроллерах.
Di и конструктор контроллера вам помогут в этом.

2 ArticleRepository: у каждого репозитория (в идеале) должен быть интерфейс который он реализует. ArtcileRepositoryInterface или что-то типа того. Потом делаете конкретную реализацию: ArticleArRepository или ArticleDAORepositroy и т.д. Методы репозитория не статичтны, репозиторий инжектится к контроллер как и в п.1 через конструктор.

3 Удаление и создание статьи должно идти через репозиторий (у вас через сервис), т.к. именно репозиторий абстрагирует хранилище.
Можно (имхо) продублировать это в сервис (но удалять все равно через репозиторий) если удаление или создание статьи сопровождается дополнительным функционалом: генерация события, отправка уведомления и т.д.


Чтобы прочувствовать на практике это все хотябы частично есть очень простой совет - перепишите ваш пример только забудьте про ActiveRecord от Yii2, возьмите Doctrine2, а контроллеры, вьюхи и все прочее оставьте от Уии.