Yii терминология Слоистой архитектуры

Обсуждаем, как правильно строить приложения
Аватара пользователя
mihail_dev
Сообщения: 243
Зарегистрирован: 2013.07.17, 00:51
Откуда: Молдова
Контактная информация:

Yii терминология Слоистой архитектуры

Сообщение mihail_dev »

Мозг кипит

Всегда думал что неплохо разбираюсь в Yii
Но на днях мне дали проект новый который нужно частично переписать и создать кучу тестов. Я подумал надо освежить знания в архитектуре и тестировании. И тут наткнулся на новое магические слова “Слоистая архитектура”. и чем больше я погружался в слои тем больше у меня появлялось вопросов и немного подташнивало.
Сейчас у разных великих просветителей по Yii разные подходы в реализации “Слоистой архитектуры”. Мне нравится Yii и я стараюсь максимально придерживаться философии написания поэтому хотел бы узнать в каком направлении мне правильнее думать.

Пожалуйста не пишите тут про академичность проекта … Я просто работаю мне нужен оптимальный путь!
  1. Сервисы - такого слова я до сих пор не знал, точнее представлял как какое то стороннее апи. Прочитав и увидев пару реализаций я сделал вывод что они ничем не отличаются от обычных Компонент. И тут вопрос зачем мне Сервисы если есть Компоненты?
  2. Также Модули - в моём представлении это Компонента + Контроллер то есть по сути Модуль может выполнять роль Сервиса!?
  3. Почитав Дмитрия Елисеева увидев DTO мне стало вообще весело и тут вопрос на сколько такой подход необходим и оправдан в Yii? и для чего ломать каноны Yii?

Я разработчик с 15 летним стажем, ещё лет 7 назад начал практиковать вынесение логики в Компоненты или Модули стандартными для Yii методами а сейчас мне говорят что вот так нормально для контроллера:

Код: Выделить всё

public function __construct($id, $module, ArtistService $artistService)
{
   $this->artistService = $artistService;
   parent::__construct($id, $module);

}

для мне переписывать стандартную работу конструктора только для того чтоб воспользоваться DI как то дергает глаз.
Изображение

Аватара пользователя
ElisDN
Сообщения: 5669
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение ElisDN »

mihail_dev писал(а):
2020.08.24, 12:38
Сейчас у разных великих просветителей по Yii разные подходы в реализации “Слоистой архитектуры”.
Но идея одна. Вместо написания абсолютно всего в контроллере разносить всё на слои как у того же Елисеева в докладе о слоях. Чтобы не было путаницы и пересечений.
mihail_dev писал(а):
2020.08.24, 12:38
И тут вопрос зачем мне Сервисы если есть Компоненты?
Компоненты в Yii - это и есть сервисы. Просто в Yii придумали свой способ их написания для дёрганья через сервис-локатор Yii::$app и вместо Сервисов назвали их Компонентами Приложения.
mihail_dev писал(а):
2020.08.24, 12:38
А сейчас мне говорят что вот так нормально для контроллера...
В остальном современном PHP-мире кроме Yii всё делают как раз так через DI. Там и конструкторы сервисов используют по назначению, а не конфигурируют всё публичными полями как в Yii.

Так что это Yii приучил вас много чего делать только по его старым канонам, а не так, как сейчас делают в остальных фреймворках. Так что зная только Yii будет сложно сделать что-то без него.
mihail_dev писал(а):
2020.08.24, 12:38
Также Модули - в моём представлении это Компонента + Контроллер то есть по сути Модуль может выполнять роль Сервиса!?
Нет. Сама Компонента выполняет роль сервиса. А модуль - это именно самодостаточная пачка из контроллеров, сервисов, сущностей, представлений и всего остального.
mihail_dev писал(а):
2020.08.24, 12:38
Мне нравится Yii и я стараюсь максимально придерживаться философии написания...
И тут вопрос на сколько такой подход необходим и оправдан в Yii? и для чего ломать каноны Yii?
Как раз смысл слоистых и подобных гексагональных архитектур в том, чтобы писать чистый код на голом PHP с переносимыми компонентами, не привязываясь к канонам какого-то конкретного фреймворка. Чтобы в итоге не стать заложником одного фреймворка как у вас сейчас:

Yii2 вышел в 2014-ом году как немного переписанная версия Yii1.1 из 2011-го. Он до сих пор ориентируется на PHP 5.4. Все шесть лет он архитектурно не развивался. С 2018-ого его разработка заморожена.

Так что сейчас вы пишите проекты на заброшенном два года назад фреймворке Yii2 шестилетней давности, написанном по канонам Yii1 девятилетней давности. Если выйдет Yii3, то там многих из этих канонов уже не будет.

И вы сейчас не можете просто так взять свой проект и перенести на любой более современный фреймворк. Так как если весь ваш проект написан по канонам Yii, то для перехода придётся переписать все 100% кода. А если бы у вас было 80% переносимого кода по общеупотребительным практикам и 20% смежного, то пришлось бы только переписать контролеры и адаптеры.

Вам остаётся либо продолжать сидеть на всё более устаревающем Yii2, либо смотреть и на другие фреймворки и подходы.
mihail_dev писал(а):
2020.08.24, 12:38
И тут вопрос на сколько такой подход необходим и оправдан в Yii? и для чего ломать каноны Yii?
Если это одноразовый проект, который один раз написали и забыли, то делать можно на чём угодно и как угодно. Но если проект делают надолго, то чтобы обезопасить себя от сложности таких постоянных переписываний выбирают сразу более свободные и независимые подходы. Это как у того же Елисеева рассказано здесь.

Либо, как крайний вариант, вместо готовых фреймворков сами под свои нужды собирают проект из нужных компонентов на минимальном микрофреймворке как здесь.

Аватара пользователя
mihail_dev
Сообщения: 243
Зарегистрирован: 2013.07.17, 00:51
Откуда: Молдова
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение mihail_dev »

ElisDN писал(а):
2020.08.24, 16:01
Просто в Yii придумали свой способ их написания для дёрганья через сервис-локатор Yii::$app и вместо Сервисов назвали их Компонентами Приложения.
Я не вижу тут ничего плохого! У меня не стоит задача создать Крос Фрэймворкавский код! я работаю именно с Yii! на данный момент он удовлетворяет меня в 99% случаев а в 1% я дописываю!
ElisDN писал(а):
2020.08.24, 16:01
В остальном современном PHP-мире кроме Yii всё делают как раз так через DI. Там и конструкторы сервисов используют по назначению, а не конфигурируют всё публичными полями как в Yii.
это академичность а не реальность! в реальности мало средних проектов готовы платить за академичность!
ElisDN писал(а):
2020.08.24, 16:01
Нет. Сама Компонента выполняет роль сервиса. А модуль - это именно самодостаточная пачка из контроллеров, сервисов, сущностей, представлений и всего остального.
ну я обычно создавал Компоненты модуля и через модуль ими пользовался!
а модуль отвечал за взаимодействие с другими частями проекта!
ElisDN писал(а):
2020.08.24, 16:01
Так что это Yii приучил вас делать только по его старым канонам
а что тут плохого? выйдут новые будем переучиваться, но я думаю что будет с адаптацией!
ElisDN писал(а):
2020.08.24, 16:01
Как раз смысл слоистых и подобных гексагональных архитектур в том, чтобы писать чистый код на голом PHP
Ну да мне всегда нравилось когда разговор переходит в раздел звёздных воин!
Это как REST собрали старый опыт и старые технологии в одно! Некоторые новички у меня просто боятся этого слова но когда я им говорю ты знаешь как сделать POST и GET запросы он отвечает что знает а вот об остальных типах он просто не знал так как ими редко пользуются!
Пожалуйста я хочу определится как не нарушая каноны Yii так скажем повысить академичность найти баланс!

ElisDN писал(а):
2020.08.24, 16:01
Так что сейчас вы пишите проекты на заброшенном два года назад фреймворке Yii2 шестилетней давности, написанном по канонам Yii1 девятилетней давности. Если выйдет Yii3, то там многих из этих канонов уже не будет.

И вы сейчас не можете просто так взять свой проект и перенести на любой более современный фреймворк. Так как если весь ваш проект написан по канонам Yii, то для перехода придётся переписать все 100% кода.
мне кажется вы тут преувеличили! у любого проекта могут быть сложности но я не думаю что данный фрэймворк умрёт!
я думаю что Yii3 распавшись на части сможет более быстрее догнать разницу!
по поводу переписывания логика проекта не изменится компоненты останутся возможно предаётся пересмотреть все части это да возможно что то исправлять! надеюсь будет мягкий переход со 2 версии!

даже если предположить самы плохой вариант на данный момент мне с головой хватает и 2 версии!
Изображение

Аватара пользователя
maleks
Сообщения: 1927
Зарегистрирован: 2012.12.26, 12:56

Re: Yii терминология Слоистой архитектуры

Сообщение maleks »

mihail_dev писал(а):а что тут плохого? выйдут новые будем переучиваться, но я думаю что будет с адаптацией!
надеюсь будет мягкий переход со 2 версии!
Вряд ли там будет с адаптацией. Они в новом даже AR не будут использовать
mihail_dev писал(а): Это как REST собрали старый опыт
Ну а тут - это не как REST, когда что то нужно доучить и все пойдет all right.
Если код не SOLID, если не напишешь модульные тесты, т.к. не работает без базы, то это объективные препятствия.
mihail_dev писал(а): Пожалуйста я хочу определится как не нарушая каноны Yii
Да нет никаких канонов yii. Все пишут как хотят.
Тому ваш пример:
mihail_dev писал(а): ну я обычно создавал Компоненты модуля и через модуль ими пользовался!
а модуль отвечал за взаимодействие с другими частями проекта!
А насчет
mihail_dev писал(а):так скажем повысить академичность найти баланс!
Всякий "правильный" способ работы с yii я так и не нашел, хотя было время и интересовался и искал и пробовал.
Просто пытаться писать код более solid и да, с учетом слоев, их зависимостей.
Но главный затык все равно будет на AR, на попытках отвязать ее от базы, чтобы она сохранялась только через репозитарий и т.д., решения такие становятся переусложненными и не сильно интересными на практике
Последний раз редактировалось maleks 2020.08.25, 09:36, всего редактировалось 1 раз.
Yii2 universal module sceleton - for basic and advanced templates

Аватара пользователя
maleks
Сообщения: 1927
Зарегистрирован: 2012.12.26, 12:56

Re: Yii терминология Слоистой архитектуры

Сообщение maleks »

mihail_dev писал(а):
2020.08.24, 16:57
даже если предположить самы плохой вариант на данный момент мне с головой хватает и 2 версии!
И jQuery вам наверное хватает
Yii2 universal module sceleton - for basic and advanced templates

Аватара пользователя
mihail_dev
Сообщения: 243
Зарегистрирован: 2013.07.17, 00:51
Откуда: Молдова
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение mihail_dev »

maleks писал(а):
2020.08.25, 07:32
Вряд ли там будет с адаптацией. Они в новом даже AR не будут использовать
ещё не смотрел новую версию но думаю будет что то на подобие разбиения на Model и Reposotory так было бы логично чтобы плавно перейти от AR
maleks писал(а):
2020.08.25, 07:32
Ну а тут - это не как REST, когда что то нужно доучить и все пойдет all right.
проблема не в недоучить некоторым начинающим разрабам тяжело вообще представить процесс попадания данных на сервер (неоднократно с этим сталкивался)
maleks писал(а):
2020.08.25, 07:32
Да нет никаких канонов yii. Все пишут как хотят.
Тому ваш пример:
то что каждый пишет как хочет это так но когда начинают писать DTO на Yii мне кажется лучше уже сразу перейти на другой фрэймворк!
мой пример показывает что я старался максимально воспользоватся возможностями фрэймворка так чтоб можно было пользоваться документацией и примерами
maleks писал(а):
2020.08.25, 07:32
Всякий "правильный" способ работы с yii я так и не нашел, хотя было время и интересовался и искал и пробовал.
Просто пытаться писать код более solid и да с учетом слоев, их зависимостей.
Но главный затык все равно будет на AR, на попытках отвязать ее от базы, чтобы она сохранялась только через репозитарий и т.д., решения такие становятся переусложненными и не сильно интересными на практике
Мы также стараемся где возможно использовать SOLID принципы! но я ищу возможно не совсем правильный способ а больше интуитивно понятный в рамках Yii!
maleks писал(а):
2020.08.25, 07:33
И jQuery вам наверное хватает
Нет )) Но у меня не возникает проблем с внедрением на фронте любых скриптов! а бэкенд строго на jQuery и стандартных решениях!



Ещё раз прошу всех кто имеет хоть какое то мнение и опыт в данном вопросе напишите здесь своё виденье!
Цель моя не правильность кода, я понимаю что привести на данный момент код к правильному будет сложно, я ищу баланс между правильность и Yii возможностями!
Изображение

anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Yii терминология Слоистой архитектуры

Сообщение anton_z »

А вы подумали, зачем вам AR от базы отвязывать? Чего именно вы этим добиться хотите и надо ли оно вашим работодателям?

Рецепт от меня:

1. AR юзаем как слой доступа к данным, без бизнес-логики. Валидацию там используем для проверки соответствия модели данных. Хорошо сделать в AR метод типа saveOrFail(), который выбрасывает исключение в случае ошибки валидации. Валидацию данных извне делаем только в слое форм. Никакого наследования AR. AR представляет в приложении строки из БД как они есть.
2. Всю бизнес-логику в сервисы. Сервисы покрываем юнит тестами. Другие сервисы запрашиваем через конструктор делаемого сервиса. AR создаем в этих сервисах через фабрику (без new и статики внутри сервисов, чтобы можно было мокать), либо передаем в качестве аргументов метода:

Код: Выделить всё


public function actionDoFoo(string $id, FooService $service)
{
	$bar = Bar::findOne($id);
	
	if ($model === null) {
	     throw new NotFoundHttpException();
	}
	
	$service->doFoo($bar);
	
}

Конструктор контроллера необязательно переопределять, вроде вернули внедрение через action. Сами контроллеры делаем максимально простыми: авторизация, http-фильтрация, вызов валидации форм, Rate limits, вызов сервисов, вызов представлений.

3. Сервисы регистрируем в контейнере внедрения. Интерфейсы для сервисов без острой необходимости не делаем.
4. Если между сервисами появляется дублирование, выносим дублирующийся код в новый сервис, т.е. применяем композицию. Наследование сервисов применяем в крайнем случае.
5. DTO это нормально в качестве контейнера для передачи данных между слоями, например из формы в сервис данные передать. Особенно доставляет при появляении типизированных свойств в php 7.4.

В итоге получим приложение вокруг контейнера. В принципе в SF то же самое получается (приложение вокруг контейнера), если только не делать RichDomainModel. По моим наблюдениям, сейчас люди возвращаются к AnemicDomainModel, юзая сущности Doctrine с аннотациями как слой доступа к данным, что, на мой взгляд, правильно. Рашьше я думал по-другому. Так можно писать и на Yii и на SF и на Laravel и на CakePHP, да хоть на Laminas =), хоть с DataMapper (DataMapper лишь облегчит преобразование типов и тестирование), хоть c AR. Универсальный подход.

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

Сейчас работаю на SF, там своих нюансов, магии и говнокода хватает. Не надо думать что в SF всё так радужно. Doctrinе ORM, в отличие от Yii накладывает свои ограничения на дизайн БД, фактически подталкивая к созданию суррогатных ключей для всех сущностей. Особенно это чувствуется при использовании внешнего ключа в качестве части первичного. Если юзаешь доктрину, то старая схема, пусть даже очень хорошая, под нее может не подойти. Это ограничивает рефакторинг старых приложений на SF. Безусловно, DataMapper имеет свои преимущества, а именно возможность сменить СУБД и более простое тестирование.

P.S.
Конечно, yii давно не выпускют мажорной версии, для нового проекта лучше что-то другое. Тем не менее, архитектура веб-приложений на сервере особо и не изменилась с 2014 года. В основном фронтенд поменялся, ну еще GraphQL обороты набирает. Мода на гексагон и фреймоврконезависимость, думаю, пройдет. Одно время все с шиной команд и запросов носились, где сейчас это всё? =) Слабая сторона Yii это фронтенд и виджеты, но можно систему ассетов yii выкинуть и сделать свою сборку на webpack и все нормально будет. Также очень не нравится использоване AR в качестве REST-ресурсов, но это тоже можно обойти.


Это мое скромное мнение, как практикующего разработчика. Я ничего не продаю и не рекламирую.
Последний раз редактировалось anton_z 2020.08.26, 02:17, всего редактировалось 4 раза.

Аватара пользователя
ElisDN
Сообщения: 5669
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение ElisDN »

mihail_dev писал(а):
2020.08.24, 16:57
в реальности мало средних проектов готовы платить за академичность!
Ну вам, как человеку, знающему только один упрощённый старый RAD-фреймворк и не знающему остальных, виднее, как обстоят дела во всём остальном современном PHP-мире снаружи Yii.
mihail_dev писал(а):
2020.08.24, 16:57
выйдут новые будем переучиваться, но я думаю что будет с адаптацией! надеюсь будет мягкий переход со 2 версии!
...
думаю будет что то на подобие разбиения на Model и Reposotory так было бы логично чтобы плавно перейти от AR
Не будет с простой адаптацией. Переход с Yii1 на Yii2 был сложным. И сейчас переход тоже будет большим.
mihail_dev писал(а):
2020.08.24, 16:57
Это как REST собрали старый опыт и старые технологии в одно! Некоторые новички у меня просто боятся этого слова но когда я им говорю ты знаешь как сделать POST и GET запросы он отвечает что знает а вот об остальных типах он просто не знал так как ими редко пользуются!
...
проблема не в недоучить некоторым начинающим разрабам тяжело вообще представить процесс попадания данных на сервер (неоднократно с этим сталкивался)
Как и вы здесь слабо представляете, что значит REST. Это не про методы запросов.
mihail_dev писал(а):
2020.08.24, 16:57
мне кажется вы тут преувеличили! у любого проекта могут быть сложности но я не думаю что данный фрэймворк умрёт!
я думаю что Yii3 распавшись на части сможет более быстрее догнать разницу!
Yii2 уже умер. Yii3 ещё не выпущен. Может через год выпустят, а может через три. У разработки Yii никогда не было точного расписания и точного вектора развития, так что никто не знает, что и когда в нём будет.
mihail_dev писал(а):
2020.08.24, 16:57
по поводу переписывания логика проекта не изменится компоненты останутся возможно предаётся пересмотреть все части это да возможно что то исправлять!
Вот именно, что вам придётся пересмотреть и исправить все части. Я свой сайт с Yii1 на Yii2 так переводил четыре месяца. Больше так заморачиваться не хочу.
mihail_dev писал(а):
2020.08.25, 10:16
то что каждый пишет как хочет это так но когда начинают писать DTO на Yii мне кажется лучше уже сразу перейти на другой фрэймворк!
Верно. Поэтому вместо Yii и берут сейчас более академические и свежие фреймворки, не ограниченные своими спорными канонами.
mihail_dev писал(а):
2020.08.24, 16:57
Пожалуйста я хочу определится как не нарушая каноны Yii так скажем повысить академичность найти баланс!
Никак. Yii специально для упрощения и скорости сделан антиакадемичным. И многие его каноны являются антипаттернами.
mihail_dev писал(а):
2020.08.24, 16:57
Я не вижу тут ничего плохого! Я работаю именно с Yii! на данный момент он удовлетворяет меня в 99% случаев а в 1% я дописываю!
...
Мы также стараемся где возможно использовать SOLID принципы! но я ищу возможно не совсем правильный способ а больше интуитивно понятный в рамках Yii!
Если бы вы действительно использовали у себя SOLID, то бы сразу заметили, что фреймворк внутри на 99% противоречит SOLID. А раз не замечаете, то либо что-то недоговариваете, либо понимаете SOLID также смутно как REST.
mihail_dev писал(а):
2020.08.25, 10:16
Нет )) Но у меня не возникает проблем с внедрением на фронте любых скриптов! а бэкенд строго на jQuery и стандартных решениях!
А у меня возникает. Так как для классического фронта фреймворк всюду тащит свои встроенные ассеты с jQuery. И чтобы перейти на WebPack надо это из всех мест вычищать. А если делать отдельный JS-фронт, то для построения API половина фреймворка оказывается не нужна.
mihail_dev писал(а):
2020.08.24, 16:57
даже если предположить самы плохой вариант на данный момент мне с головой хватает и 2 версии!
Если вам хватает технологий Yii, JQuery и PHP 5.4 шестилетней давности, то получайте удовольствие.

Мне больше нравится свежий подход с настоящим DI-контейнером, типами PHP 7.4, PSR и свежим JS/TS с WebPack.
mihail_dev писал(а):
2020.08.25, 10:16
Ещё раз прошу всех кто имеет хоть какое то мнение и опыт в данном вопросе напишите здесь своё виденье!
Я озвучил видение, что это заброшенный фреймворк со старыми противоречивыми и часто вредными канонами. И что ваши знания с ним настолько же сильно устарели. Нравится вам это или нет, но это так. Но вы сразу:
mihail_dev писал(а):
2020.08.24, 16:57
Я не вижу тут ничего плохого!
это академичность а не реальность!
мне всегда нравилось когда разговор переходит в раздел звёздных воин!
Если не нравятся ответы, то не задавайте такие вопросы.

Аватара пользователя
samdark
Администратор
Сообщения: 9405
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение samdark »

1. Канонов жёстких нет.
2. Инъектить сервисы-компоненты в action Yii 2 научился, контейнер прокачался и им можно сильно меньше пользоваться как service locator.
3. Yii 2 не умер. Релизим, улучшаем. Поддерживать будем ещё довольно долго.
4. asset-ы в Yii 2 выключаются одной строчкой в конфиге. Не знаю что там нужно вычищать и из каких мест...

Аватара пользователя
mihail_dev
Сообщения: 243
Зарегистрирован: 2013.07.17, 00:51
Откуда: Молдова
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение mihail_dev »

ElisDN писал(а):
2020.08.25, 16:16
Если не нравятся ответы, то не задавайте такие вопросы.
я вижу вы просто против Yii! вас что в сообществе обидели? я учился на ваших примерах считаю клёвым разрабом (книгу по Yii писали) но реальность такова проектам более 5 лет и ближайшие 5 лет мин их не собираются сворачивать или переписывать! приходят новые разрабы которые учатся на новых веяниях (кстати которые непосредственно вы продвигаете) и потом в проекте появляется GCODE(я его так обозвал)! вроде сделали по фэншую а получилось что прикрутили 5 колесо! я понимал бы вас если бы вы отказались от любых комментариев кроме как не пользуйтесь Yii2 ждём 3 версии и точка! но вы выпустили много материала как сломать Yii чтоб потом выкинуть проект!

я тимлид мне надо выработать стратегию как вести свои проекты, как объяснять подчиненным не ломая у них психику и руки (вроде как их правильно учили)
anton_z писал(а):
2020.08.25, 15:52
Рецепт от меня:
Огромное спасибо! первый свет в конце тоннеля!
samdark писал(а):
2020.08.25, 17:18
1. Канонов жёстких нет.
2. Инъектить сервисы-компоненты в action Yii 2 научился, контейнер прокачался и им можно сильно меньше пользоваться как service locator.
3. Yii 2 не умер. Релизим, улучшаем. Поддерживать будем ещё довольно долго.
4. asset-ы в Yii 2 выключаются одной строчкой в конфиге. Не знаю что там нужно вычищать и из каких мест...
1) Но всё же каноны есть, не жесткие!
2) Походу всё же придётся обновляться до последней версии
3) :twisted:
4) 100%
Изображение

Аватара пользователя
samdark
Администратор
Сообщения: 9405
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение samdark »

1) Ну не то чтобы прям каноны. Есть как показано в гайде, но так показано потому что это проще всего, а не потому что это единственно правильный вариант. Я видел много проектов на Yii 2 в совершенно разных стилях. Практически во всех были и хорошие проекты и плохие.
2) Ну, это всегда стоит делать. Хотя-бы из за багфиксов и безопасности.

anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Yii терминология Слоистой архитектуры

Сообщение anton_z »

mihail_dev писал(а):
2020.08.25, 22:18

приходят новые разрабы которые учатся на новых веяниях (кстати которые непосредственно вы продвигаете) понимал бы вас если бы вы отказались от любых комментариев кроме как не пользуйтесь Yii2 ждём 3 версии и точка! но вы выпустили много материала как сломать Yii чтоб потом выкинуть проект!
Это хитрый план :D

mihail_dev писал(а):
2020.08.25, 22:18
Огромное спасибо! первый свет в конце тоннеля!
Рад помочь :D Могу в выходной даже бесплатно поревьюить или просто пообщаться (поболтать) об этом по скайпу или телеге, если это не будет слишком долго. Приятно видеть, когда люди, особенно тимлиды, думают и ищут эффективные решения, а не кидаются сломя голову в паттерны и DDD.

Аватара пользователя
ElisDN
Сообщения: 5669
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение ElisDN »

mihail_dev писал(а):
2020.08.25, 22:18
я вижу вы просто против Yii! вас что в сообществе обидели?
Я против монолитного негибкого GCODE, который вы называете канонами Yii. Подробно это обсуждал здесь.
mihail_dev писал(а):
2020.08.25, 22:18
но реальность такова проектам более 5 лет и ближайшие 5 лет мин их не собираются сворачивать или переписывать!
Значит вас устраивает десять лет ковырять легаси и ничего нового не надо. Но не все такие.
mihail_dev писал(а):
2020.08.25, 22:18
приходят новые разрабы которые учатся на новых веяниях (кстати которые непосредственно вы продвигаете) и потом в проекте появляется GCODE (я его так обозвал)! вроде сделали по фэншую а получилось что прикрутили 5 колесо!
Тогда в своих вакансиях прямо пишите, что феншуи не нужны.
mihail_dev писал(а):
2020.08.25, 22:18
я понимал бы вас если бы вы отказались от любых комментариев кроме как не пользуйтесь Yii2 ждём 3 версии и точка!
Не пользуйтесь Kohana, Yii1 и Yii2 для новых проектов, так как они уже устаревшие и функционально заброшенные.

Не ждите 3 версии, так как не дождётесь.
mihail_dev писал(а):
2020.08.25, 22:18
но вы выпустили много материала как сломать Yii чтоб потом выкинуть проект!
Я выпустил много материала о том, как выкинуть их проекта GCODE-каноны Yii.
mihail_dev писал(а):
2020.08.25, 22:18
я тимлид мне надо выработать стратегию как вести свои проекты, как объяснять подчиненным не ломая у них психику и руки (вроде как их правильно учили)
Ну если вы лид, то и ведите как умеете и как считаете нужным.

Аватара пользователя
chungachguk
Сообщения: 435
Зарегистрирован: 2012.07.17, 11:52

Re: Yii терминология Слоистой архитектуры

Сообщение chungachguk »

Не ждите 3 версии, так как не дождётесь.
Это мне напоминает ситуацию с Kohana 3.3 (кажется) версией. Тоже ждали-ждали и не дождались. И люди массово перешли на Laravel.

Аватара пользователя
mihail_dev
Сообщения: 243
Зарегистрирован: 2013.07.17, 00:51
Откуда: Молдова
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение mihail_dev »

ElisDN спасибо за ваш комментарий

chungachguk всё может быть но я точно знаю что ближайшие 5 лет я буду с YII
Изображение

Аватара пользователя
mihail_dev
Сообщения: 243
Зарегистрирован: 2013.07.17, 00:51
Откуда: Молдова
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение mihail_dev »

anton_z писал(а):
2020.08.26, 02:06
Рад помочь :D Могу в выходной даже бесплатно поревьюить или просто пообщаться (поболтать) об этом по скайпу или телеге, если это не будет слишком долго. Приятно видеть, когда люди, особенно тимлиды, думают и ищут эффективные решения, а не кидаются сломя голову в паттерны и DDD.
маленький пример был бы очень кстати! заранее спасибо!
Изображение

uEhlO4a
Сообщения: 70
Зарегистрирован: 2017.08.12, 19:19

Re: Yii терминология Слоистой архитектуры

Сообщение uEhlO4a »

иногда захожу сюда почитать, некоторые вещи не меняются, ElisDN всё так же .... в разработке. Хотя что-то поменялось, что-то не вижу слова "Doctrine" у него... как же так?! Как же куча лохов которые впарили клиентам эту х..ету по твоему совету... :D


mihail_dev

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

Я сейчас работаю в компании +20 разработчиков, используется command bus, repository, entity, dto, enum и еще куча всякой ерунды.. префиксы и суфиксы к классам т.к. проект большой модульный монолит.. тесты гоуноу и т.д..
Но главная вещь - это команда. Я закрывая глаза и пишу этот конченный префикс к классу и живу с этим, и это намного лучше чем если бы я один не писал потому что "так хочу". И не потому что "слоистость", а потому что "принцип".

Если ты как лид, спроектировал проект так, что для добавления нового функционала тебе не нужно переписывать десяток классов - значит всё супер. Я был лидом, и как лиду скажу самое сложное это няньчиться с разработчиками, сю-сю-сю и т.д. При найме всегда говоришь, что он будет работать с тем-то тем-то и это -50% проблем. Если в команде есть активный дев, который тебя закидывает новостями - читай. Я тоже закидывал своего лида новостями.. и он тоже сопротивлялся :D и считаю это нормальным. И меня закидывали новостями.. и я сопротивлялся, потому что проекту нужна стабильность, а при обновлении план миграции.. но! если он может продемонстрировать пример и всё будут в "ваааааааау!"эффекте - возможно стоит задуматься об интеграции даного подхода как "принцип".

Насчет DI в контроллере - на личном опыте, это 50%50. И не плохо и не хорошо. Ты размениваешь возможность подменять класс (дополнительной "слоистостью"?) вместо написания дополнительного класса типа фабрика. НО! Хреново, когда у тебя есть возможность использовать DI а ты городишь лес и используешь фабрику или еще какую-то "феймворконезависимую" штуку. На проекте в +200Мб кода это выглядит как "руки из жопы растут". Главное это команда, диалог и принципы.

Service Locator - отличная вещь. И это слой. Смотря как использовать. На DI контейнере можно и такое написать

Код: Выделить всё

public function __construct($id, $module, Container $c)
{
   $c->get(ArtistService::class)->...
}
и как по мне это будет хуже чем

Код: Выделить всё

public function __construct($id, $module)
{
   App::get(ArtistService::class)->...
}
И пускай тебе не парят мозг про static и т.д. Даже в случае армагедона у тебя всегда есть https://www.php.net/manual/en/intro.runkit.php
главное правильность использования языка. Я столько раз видел, когда на trait начали переводить всё и вся..

Аватара пользователя
samdark
Администратор
Сообщения: 9405
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение samdark »

Не пользуйтесь Kohana, Yii1 и Yii2 для новых проектов, так как они уже устаревшие и функционально заброшенные.

Не ждите 3 версии, так как не дождётесь.
Ну не надо так категорично, а то ведь поверят :) Никуда 3.0 не денется. Пилим активно, пакеты релизим. Выйдет.

Что такое "функционально заброшенные"? Мега-фичи не нарастают каждый релиз? Yii 1.1 и Yii 2.0 смогут со следующего релиза работать с PHP 8. В 2.0, в том числе, мягко залетают небольшие и не очень небольшие (вроде дополнений в DI) улучшения.

Ну и про "не пользуйтесь" или "пользуйтесь" - это не догма. Нужно всегда оценивать плюсы и минусы.

Аватара пользователя
ElisDN
Сообщения: 5669
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение ElisDN »

samdark писал(а):
2020.08.31, 13:58
Ну не надо так категорично, а то ведь поверят :) Никуда 3.0 не денется. Пилим активно, пакеты релизим. Выйдет.
В каком году выйдет 3.0?
Когда примерно зарелизится 3.1?
samdark писал(а):
2020.08.31, 13:58
Что такое "функционально заброшенные"?
То, что здесь обозначено как "Feature freeze. Enhancements are no longer accepted" с февраля 2018 года.
samdark писал(а):
2020.08.31, 13:58
Мега-фичи не нарастают каждый релиз?
Новые мега-фичи не появляются, имеющиеся не меняются, легаси не чистится, фичи свежего PHP не внедряются. А это:
samdark писал(а):
2020.08.31, 13:58
Yii 1.1 и Yii 2.0 смогут со следующего релиза работать с PHP 8
не активное развитие фреймворка, а "Security and PHP compatibility fixes only".
samdark писал(а):
2020.08.31, 13:58
мягко залетают небольшие и не очень небольшие (вроде дополнений в DI) улучшения.
Именно. По истории видим, что после января 2019 года залетели только сотни небольших правок (Bug) и ~30 обратно совместимых микро-улучшений (Enh) вроде добавления нового параметра в валидатор. А все обратно несовместимые улучшения заморожены.

Аватара пользователя
samdark
Администратор
Сообщения: 9405
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Yii терминология Слоистой архитектуры

Сообщение samdark »

В каком году выйдет 3.0?
Пока estimate конец 2020 — начало 2021.
Когда примерно зарелизится 3.1?
2021.
То, что здесь обозначено как "Feature freeze. Enhancements are no longer accepted" с февраля 2018 года.
По факту немного не так. Кажется, я косякнул в описании. Зафиксил.

К тому же, к extension-ам это всё не относится. Вот, например, ElasticSearch недавно был релиз мажорной версии.
Новые мега-фичи не появляются, имеющиеся не меняются, легаси не чистится, фичи свежего PHP не внедряются.
- Имеющиеся меняются. Тот же DI пример.
- Легаси чистится - баги мы правим как надо. Если речь про "поднять версию PHP и выпилить всё что не надо для новой", то это про Yii 3 уже.
не активное развитие фреймворка, а "Security and PHP compatibility fixes only"
Как я уже написал выше, это немного не так, его говорить про Yii 2. Но, конечно, прям новое-новое — это то, что происходит в Yii 3.
А все обратно несовместимые улучшения заморожены.
Ну да. Версии 2.1 фреймворка не планируется. Всё обратно несовместимое в 2.0 не проходит. Обратно несовместимое — это про мажорную версию.

Ответить