Вечно это читаю, но так и не понял, какое решение предлагает yii. То что описано в доках отлично подходит под CRUD. Но CRUD это по-сути веб-интерфейс для правки табличек в базе. Типичное же веб-приложение несколько сложнее этого. В итоге следуя документации получается приложение с гигантскими AR классами раздутые бизнес-логикой. И самый ужас в том, что на всё это невозможно написать вменяемые юнит-тесты без участия базы данных. Весь код переплетается как спагетти. Чинишь одно, отваливается другое. Узнаешь об этом уже на продакшене, тестов же нет. Кошмар.
Слоистая архитектура для Yii приложений
Re: Слоистая архитектура для Yii приложений
Re: Слоистая архитектура для Yii приложений
Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.
(1) У человека есть запас ресурсов (время и деньги). В этом случае специалист продолжает расти, ищет компании, которые работают со сложными слоёными архитектурами, пробует новые технологии, идеи. На Yii уже не возвращается, лишь иногда вспоминает его в качестве входной точки в web-dev.
(2) У человека ограниченный запас ресурсов (нет времени и/или денег, нужно содержать семью, зарабатывать здесь и сейчас). В этом кейсе приходится возвращаться на AR, чтобы делать быстро-заказы на фрилансе или быстро устроиться на работу (RAD на рынке востребован).
Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
Re: Слоистая архитектура для Yii приложений
Кое какие тесты все же можно написать. Но конечно, если разрабатывать слоисто, то уже и Yii как таковой не нужен. Ну кроме облегчения некоторых рутинных вещей.sda писал(а): ↑2017.04.12, 13:56Вечно это читаю, но так и не понял, какое решение предлагает yii. То что описано в доках отлично подходит под CRUD. Но CRUD это по-сути веб-интерфейс для правки табличек в базе. Типичное же веб-приложение несколько сложнее этого. В итоге следуя документации получается приложение с гигантскими AR классами раздутые бизнес-логикой. И самый ужас в том, что на всё это невозможно написать вменяемые юнит-тесты без участия базы данных. Весь код переплетается как спагетти. Чинишь одно, отваливается другое. Узнаешь об этом уже на продакшене, тестов же нет. Кошмар.
Но проблема в том, что мало кто умеет писать так, чтобы не зависеть от Yii (ну, я по крайней мере не на 100% это пока умею).
Re: Слоистая архитектура для Yii приложений
Я начал новый проект на работе на Yii2 с мыслями о том, что надо делать такую архитектуру, которая потом может гибко меняться не зависимо от базы, AR и прочего. Не зная о слоистой архитектуре. В итоге судьба меня привела в эту ветку и я уже месяц пытаюсь понять как это так организовать архитектуру слоев, чтобы не писать лапши и делать все грамотно. И честно, наследие Yii в виде легкой разработки с AR не дает мне вставть на нужные рельсы. По чуть-чуть мысли устаканиваются, а вот быстро начать писать правильно не выходит. Вот и приходится учится но пока писать используя некий симбиоз из правильных слоев и ARrugabarbo писал(а): ↑2017.04.12, 14:05Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.
(1) У человека есть запас ресурсов (время и деньги). В этом случае специалист продолжает расти, ищет компании, которые работают со сложными слоёными архитектурами, пробует новые технологии, идеи. На Yii уже не возвращается, лишь иногда вспоминает его в качестве входной точки в web-dev.
(2) У человека ограниченный запас ресурсов (нет времени и/или денег, нужно содержать семью, зарабатывать здесь и сейчас). В этом кейсе приходится возвращаться на AR, чтобы делать быстро-заказы на фрилансе или быстро устроиться на работу (RAD на рынке востребован).
Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
Re: Слоистая архитектура для Yii приложений
присоединяюсь. Только в качестве первопричины первого назвал бы не время и деньги, а талант, опыт, обучаемость, желание научиться. Время и деньги - это скорее производные.rugabarbo писал(а): ↑2017.04.12, 14:05Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.
(1) У человека есть запас ресурсов (время и деньги). В этом случае специалист продолжает расти, ищет компании, которые работают со сложными слоёными архитектурами, пробует новые технологии, идеи. На Yii уже не возвращается, лишь иногда вспоминает его в качестве входной точки в web-dev.
(2) У человека ограниченный запас ресурсов (нет времени и/или денег, нужно содержать семью, зарабатывать здесь и сейчас). В этом кейсе приходится возвращаться на AR, чтобы делать быстро-заказы на фрилансе или быстро устроиться на работу (RAD на рынке востребован).
Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
Re: Слоистая архитектура для Yii приложений
главная ошибка - от непонимания проблем, решаемых слоистой архитектурой. Иначе было бы ясно, что AR не вписывается.vitovt писал(а): ↑2017.04.12, 14:10Я начал новый проект на работе на Yii2 с мыслями о том, что надо делать такую архитектуру, которая потом может гибко меняться не зависимо от базы, AR и прочего. Не зная о слоистой архитектуре. В итоге судьба меня привела в эту ветку и я уже месяц пытаюсь понять как это так организовать архитектуру слоев, чтобы не писать лапши и делать все грамотно. И честно, наследие Yii в виде легкой разработки с AR не дает мне вставть на нужные рельсы. По чуть-чуть мысли устаканиваются, а вот быстро начать писать правильно не выходит. Вот и приходится учится но пока писать используя некий симбиоз из правильных слоев и ARrugabarbo писал(а): ↑2017.04.12, 14:05Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.
(1) У человека есть запас ресурсов (время и деньги). В этом случае специалист продолжает расти, ищет компании, которые работают со сложными слоёными архитектурами, пробует новые технологии, идеи. На Yii уже не возвращается, лишь иногда вспоминает его в качестве входной точки в web-dev.
(2) У человека ограниченный запас ресурсов (нет времени и/или денег, нужно содержать семью, зарабатывать здесь и сейчас). В этом кейсе приходится возвращаться на AR, чтобы делать быстро-заказы на фрилансе или быстро устроиться на работу (RAD на рынке востребован).
Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
Re: Слоистая архитектура для Yii приложений
Я понимаю, что в какой-то степени AR это дубль одного слоя.zelenin писал(а): ↑2017.04.12, 14:14главная ошибка - от непонимания проблем, решаемых слоистой архитектурой. Иначе было бы ясно, что AR не вписывается.vitovt писал(а): ↑2017.04.12, 14:10Я начал новый проект на работе на Yii2 с мыслями о том, что надо делать такую архитектуру, которая потом может гибко меняться не зависимо от базы, AR и прочего. Не зная о слоистой архитектуре. В итоге судьба меня привела в эту ветку и я уже месяц пытаюсь понять как это так организовать архитектуру слоев, чтобы не писать лапши и делать все грамотно. И честно, наследие Yii в виде легкой разработки с AR не дает мне вставть на нужные рельсы. По чуть-чуть мысли устаканиваются, а вот быстро начать писать правильно не выходит. Вот и приходится учится но пока писать используя некий симбиоз из правильных слоев и ARrugabarbo писал(а): ↑2017.04.12, 14:05
Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.
(1) У человека есть запас ресурсов (время и деньги). В этом случае специалист продолжает расти, ищет компании, которые работают со сложными слоёными архитектурами, пробует новые технологии, идеи. На Yii уже не возвращается, лишь иногда вспоминает его в качестве входной точки в web-dev.
(2) У человека ограниченный запас ресурсов (нет времени и/или денег, нужно содержать семью, зарабатывать здесь и сейчас). В этом кейсе приходится возвращаться на AR, чтобы делать быстро-заказы на фрилансе или быстро устроиться на работу (RAD на рынке востребован).
Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
Согласен, от избытка информации не всегда улавливаешь основную простую суть. Пдскажите?
Re: Слоистая архитектура для Yii приложений
Конечно. Можно писать интеграционные тесты с участием базы, но они долгие и ломкие. Если их начать писать в промышленных масштабах вместо юнит-тестов, то будет ситуация, когда перед выкатыванием в продакшн нужно полсуток ждать, пока эти тесты пройдут, а если не пройдут то фиксить и ждать еще полсуток. Поскольку они довольно ломкие, а код спагетти, то очень скоро, все начнут выкатываться в продакшн с красными тестами
Я уж не говорю про функциональные.
Re: Слоистая архитектура для Yii приложений
Ну можно и модели проверить, пусть и с базой, фикстуры поюзать.sda писал(а): ↑2017.04.12, 14:58Конечно. Можно писать интеграционные тесты с участием базы, но они долгие и ломкие. Если их начать писать в промышленных масштабах вместо юнит-тестов, то будет ситуация, когда перед выкатыванием в продакшн нужно полсуток ждать, пока эти тесты пройдут, а если не пройдут то фиксить и ждать еще полсуток. Поскольку они довольно ломкие, а код спагетти, то очень скоро, все начнут выкатываться в продакшн с красными тестами
Я уж не говорю про функциональные.
Re: Слоистая архитектура для Yii приложений
Можно тестировать и монолитный код. Просто это больно.
По крайнее мере больнее тестирования компонентного/слоёного.
По крайнее мере больнее тестирования компонентного/слоёного.
- slavcodev
- Сообщения: 3134
- Зарегистрирован: 2009.04.02, 21:42
- Откуда: Valencia
- Контактная информация:
Re: Слоистая архитектура для Yii приложений
Очень далековато. Причем так и не поняв сущности моих сообщений.anton_z писал(а): ↑2017.04.12, 03:16 Так я ему говорил, что DTO для вьюшки нужно для снижения зависимости этой вьюшки от всего остального. А он мне говорит "много классов" - плохо, долго вьезжать. Ну я ему на примере модели пытался показать, что "много простых и понятных классов" лучше чем "один божественный". Видать далековато взял)
1. Я не говорил о вреде большого количества классов, я говорил о неразумном размножении классов.
2. Я не говорил что DTO не нужны, а лишь говорил что мапить 1 : 1 шаблоны и DTO это не разумно. DTO объект передачи данных между слоями, так? Так что без проблем разные шаблоны могут юзать один DTO, зависит от слоев.
После опыта проектирования riсh-models, понимаешь что "много простых и понятных классов" не всегда лучше. Но это приходит позже после игр с "архитектурой", "DDD" и "SOLID".
Далеко не факт что возвращаясь используют Yii. Я например переодически открываю форум, читая этот (только) раздел.
Потому что тут весело и т.к. для меня единственное место где на русском можно пообщаться, чтоб не забыть его.
Жду Yii 3!
Re: Слоистая архитектура для Yii приложений
Ладно, ладно, не буду спорить)slavcodev писал(а): ↑2017.04.13, 02:31
Очень далековато. Причем так и не поняв сущности моих сообщений.
1. Я не говорил о вреде большого количества классов, я говорил о неразумном размножении классов.
2. Я не говорил что DTO не нужны, а лишь говорил что мапить 1 : 1 шаблоны и DTO это не разумно. DTO объект передачи данных между слоями, так? Так что без проблем разные шаблоны могут юзать один DTO, зависит от слоев.
После опыта проектирования riсh-models, понимаешь что "много простых и понятных классов" не всегда лучше. Но это приходит позже после игр с "архитектурой", "DDD" и "SOLID".
Re: Слоистая архитектура для Yii приложений
Привет.
Возник вопрос на счет события в entity.
Есть список комментариев. Каждый комментарий можно вручную (чекбоксом) пометить прочитанным. Соответственно в entity имеем метод:
Также в сервисе есть метод массовой пометки:
Обработка событий у меня пока не вынесена через queue, т. е. все они выполняются по ходу жизни запроса.
Меня смущает тот факт, что когда я вешаю слушатель на это событие, который выполняет отправку во внешний сервис firebase, на внешний socket сервис и т. д., то когда юзер помечает 200 непрочитанных сущностей, - система прилично подвисает.
Если же кодить в лоб, то я бы собрал в сервисном слое массив id изменяемых сущностей, затем после цикла по изменению сущностей отправил бы одним внешним запросом массив этих изменных id. А так я получаю 200 коннектов/дисконнектов на внешний сервис.
Как тут правильно поступить?
Спасибо.
Возник вопрос на счет события в entity.
Есть список комментариев. Каждый комментарий можно вручную (чекбоксом) пометить прочитанным. Соответственно в entity имеем метод:
Код: Выделить всё
public function markRead()
{
$this->is_read = 1;
$this->dta_read = date('Y-m-d H:i:s');
$this->recordEvent(new EventMarkRead($this));
}
Код: Выделить всё
private function apply($eventsUsers)
{
foreach ($eventsUsers as $eventUser) {
$eventUser->markRead();
$this->eventsUsers->save($eventUser);
}
}
Меня смущает тот факт, что когда я вешаю слушатель на это событие, который выполняет отправку во внешний сервис firebase, на внешний socket сервис и т. д., то когда юзер помечает 200 непрочитанных сущностей, - система прилично подвисает.
Если же кодить в лоб, то я бы собрал в сервисном слое массив id изменяемых сущностей, затем после цикла по изменению сущностей отправил бы одним внешним запросом массив этих изменных id. А так я получаю 200 коннектов/дисконнектов на внешний сервис.
Как тут правильно поступить?
Спасибо.
Re: Слоистая архитектура для Yii приложений
Пока что я вижу такой путь. Подключить через DI диспетчер событий в сервисном слое и передать ему событие:
На сколько это феншуйно?
Код: Выделить всё
class EventUserService
{
private $eventsUsers;
private $dispatcher;
public function __construct(EventUserRepository $eventsUsers, EventDispatcher $dispatcher)
{
$this->eventsUsers = $eventsUsers;
$this->dispatcher = $dispatcher;
}
//.......
private function apply($eventsUsers)
{
$eventsIds = [];
$id_user = 0;
foreach ($eventsUsers as $eventUser) {
$eventUser->markRead();
$this->eventsUsers->save($eventUser);
$eventsIds[] = $eventUser->id_event;
if (!$id_user) {
$id_user = $eventUser->id_user;
}
}
$this->dispatcher->dispatch(new EventMarkRead($id_user, $eventsIds));
}
}
Re: Слоистая архитектура для Yii приложений
На будущее всё удобнее вынести в queue.
А пока для экономии можно сделать групповую обработку:
Код: Выделить всё
$events = [];
foreach ($eventsUsers as $eventUser) {
$events = array_merge($events, $eventUser->releaseEvents());
}
$this->dispatcher->dispatch([new BatchEvent($events));
Re: Слоистая архитектура для Yii приложений
@mitrich создавайте новую тему, не надо тут задавать вопросы не связанные с обсуждением первого сообщения.