Слоистая архитектура для Yii приложений

Обсуждаем, как правильно строить приложения
sda
Сообщения: 334
Зарегистрирован: 2013.12.19, 09:29

Re: Слоистая архитектура для Yii приложений

Сообщение sda »

samdark писал(а): 2017.04.12, 03:01 Наигравшись в архитектуру начинаешь понимать
Оно там просто не надо и излишне.
Вечно это читаю, но так и не понял, какое решение предлагает yii. То что описано в доках отлично подходит под CRUD. Но CRUD это по-сути веб-интерфейс для правки табличек в базе. Типичное же веб-приложение несколько сложнее этого. В итоге следуя документации получается приложение с гигантскими AR классами раздутые бизнес-логикой. И самый ужас в том, что на всё это невозможно написать вменяемые юнит-тесты без участия базы данных. Весь код переплетается как спагетти. Чинишь одно, отваливается другое. Узнаешь об этом уже на продакшене, тестов же нет. Кошмар.
Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Слоистая архитектура для Yii приложений

Сообщение rugabarbo »

samdark писал(а): 2017.04.12, 03:01
люди пропадают из сообщества Yii.
На какое-то время. Потом возвращаются. Наигравшись в архитектуру начинаешь понимать, что тот же DDD... да что DDD, Data Mapper — не оптимальное решение для большинства проектов. Оно там просто не надо и излишне.
Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.

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

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

Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Re: Слоистая архитектура для Yii приложений

Сообщение vitovt »

sda писал(а): 2017.04.12, 13:56
samdark писал(а): 2017.04.12, 03:01 Наигравшись в архитектуру начинаешь понимать
Оно там просто не надо и излишне.
Вечно это читаю, но так и не понял, какое решение предлагает yii. То что описано в доках отлично подходит под CRUD. Но CRUD это по-сути веб-интерфейс для правки табличек в базе. Типичное же веб-приложение несколько сложнее этого. В итоге следуя документации получается приложение с гигантскими AR классами раздутые бизнес-логикой. И самый ужас в том, что на всё это невозможно написать вменяемые юнит-тесты без участия базы данных. Весь код переплетается как спагетти. Чинишь одно, отваливается другое. Узнаешь об этом уже на продакшене, тестов же нет. Кошмар.
Кое какие тесты все же можно написать. Но конечно, если разрабатывать слоисто, то уже и Yii как таковой не нужен. Ну кроме облегчения некоторых рутинных вещей.

Но проблема в том, что мало кто умеет писать так, чтобы не зависеть от Yii (ну, я по крайней мере не на 100% это пока умею).
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Re: Слоистая архитектура для Yii приложений

Сообщение vitovt »

rugabarbo писал(а): 2017.04.12, 14:05
samdark писал(а): 2017.04.12, 03:01
люди пропадают из сообщества Yii.
На какое-то время. Потом возвращаются. Наигравшись в архитектуру начинаешь понимать, что тот же DDD... да что DDD, Data Mapper — не оптимальное решение для большинства проектов. Оно там просто не надо и излишне.
Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.

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

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

Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
Я начал новый проект на работе на Yii2 с мыслями о том, что надо делать такую архитектуру, которая потом может гибко меняться не зависимо от базы, AR и прочего. Не зная о слоистой архитектуре. В итоге судьба меня привела в эту ветку и я уже месяц пытаюсь понять как это так организовать архитектуру слоев, чтобы не писать лапши и делать все грамотно. И честно, наследие Yii в виде легкой разработки с AR не дает мне вставть на нужные рельсы. По чуть-чуть мысли устаканиваются, а вот быстро начать писать правильно не выходит. Вот и приходится учится но пока писать используя некий симбиоз из правильных слоев и AR
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Слоистая архитектура для Yii приложений

Сообщение zelenin »

rugabarbo писал(а): 2017.04.12, 14:05
samdark писал(а): 2017.04.12, 03:01
люди пропадают из сообщества Yii.
На какое-то время. Потом возвращаются. Наигравшись в архитектуру начинаешь понимать, что тот же DDD... да что DDD, Data Mapper — не оптимальное решение для большинства проектов. Оно там просто не надо и излишне.
Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.

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

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

Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
присоединяюсь. Только в качестве первопричины первого назвал бы не время и деньги, а талант, опыт, обучаемость, желание научиться. Время и деньги - это скорее производные.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Слоистая архитектура для Yii приложений

Сообщение zelenin »

vitovt писал(а): 2017.04.12, 14:10
rugabarbo писал(а): 2017.04.12, 14:05
samdark писал(а): 2017.04.12, 03:01

На какое-то время. Потом возвращаются. Наигравшись в архитектуру начинаешь понимать, что тот же DDD... да что DDD, Data Mapper — не оптимальное решение для большинства проектов. Оно там просто не надо и излишне.
Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.

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

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

Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
Я начал новый проект на работе на Yii2 с мыслями о том, что надо делать такую архитектуру, которая потом может гибко меняться не зависимо от базы, AR и прочего. Не зная о слоистой архитектуре. В итоге судьба меня привела в эту ветку и я уже месяц пытаюсь понять как это так организовать архитектуру слоев, чтобы не писать лапши и делать все грамотно. И честно, наследие Yii в виде легкой разработки с AR не дает мне вставть на нужные рельсы. По чуть-чуть мысли устаканиваются, а вот быстро начать писать правильно не выходит. Вот и приходится учится но пока писать используя некий симбиоз из правильных слоев и AR
главная ошибка - от непонимания проблем, решаемых слоистой архитектурой. Иначе было бы ясно, что AR не вписывается.
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Re: Слоистая архитектура для Yii приложений

Сообщение vitovt »

zelenin писал(а): 2017.04.12, 14:14
vitovt писал(а): 2017.04.12, 14:10
rugabarbo писал(а): 2017.04.12, 14:05

Это вопрос свободного времени. В своём кругу бывших коллег я бы выделил два основных типа дальнейшей судьбы.

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

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

Людей, которые с радостью остаются на Yii при наличии свободных ресурсов - не видел. Первые с него ушли, вторые - вынуждены пользоваться как самым популярным RAD-решением.
Я начал новый проект на работе на Yii2 с мыслями о том, что надо делать такую архитектуру, которая потом может гибко меняться не зависимо от базы, AR и прочего. Не зная о слоистой архитектуре. В итоге судьба меня привела в эту ветку и я уже месяц пытаюсь понять как это так организовать архитектуру слоев, чтобы не писать лапши и делать все грамотно. И честно, наследие Yii в виде легкой разработки с AR не дает мне вставть на нужные рельсы. По чуть-чуть мысли устаканиваются, а вот быстро начать писать правильно не выходит. Вот и приходится учится но пока писать используя некий симбиоз из правильных слоев и AR
главная ошибка - от непонимания проблем, решаемых слоистой архитектурой. Иначе было бы ясно, что AR не вписывается.
Я понимаю, что в какой-то степени AR это дубль одного слоя.

Согласен, от избытка информации не всегда улавливаешь основную простую суть. Пдскажите?
sda
Сообщения: 334
Зарегистрирован: 2013.12.19, 09:29

Re: Слоистая архитектура для Yii приложений

Сообщение sda »

vitovt писал(а): 2017.04.12, 14:07 Кое какие тесты все же можно написать.
Конечно. Можно писать интеграционные тесты с участием базы, но они долгие и ломкие. Если их начать писать в промышленных масштабах вместо юнит-тестов, то будет ситуация, когда перед выкатыванием в продакшн нужно полсуток ждать, пока эти тесты пройдут, а если не пройдут то фиксить и ждать еще полсуток. Поскольку они довольно ломкие, а код спагетти, то очень скоро, все начнут выкатываться в продакшн с красными тестами :mrgreen:
Я уж не говорю про функциональные.
Аватара пользователя
vitovt
Сообщения: 210
Зарегистрирован: 2012.03.21, 10:37
Контактная информация:

Re: Слоистая архитектура для Yii приложений

Сообщение vitovt »

sda писал(а): 2017.04.12, 14:58
vitovt писал(а): 2017.04.12, 14:07 Кое какие тесты все же можно написать.
Конечно. Можно писать интеграционные тесты с участием базы, но они долгие и ломкие. Если их начать писать в промышленных масштабах вместо юнит-тестов, то будет ситуация, когда перед выкатыванием в продакшн нужно полсуток ждать, пока эти тесты пройдут, а если не пройдут то фиксить и ждать еще полсуток. Поскольку они довольно ломкие, а код спагетти, то очень скоро, все начнут выкатываться в продакшн с красными тестами :mrgreen:
Я уж не говорю про функциональные.
Ну можно и модели проверить, пусть и с базой, фикстуры поюзать.
Аватара пользователя
rugabarbo
Сообщения: 1063
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

Re: Слоистая архитектура для Yii приложений

Сообщение rugabarbo »

Можно тестировать и монолитный код. Просто это больно.
По крайнее мере больнее тестирования компонентного/слоёного.
Аватара пользователя
slavcodev
Сообщения: 3134
Зарегистрирован: 2009.04.02, 21:42
Откуда: Valencia
Контактная информация:

Re: Слоистая архитектура для Yii приложений

Сообщение slavcodev »

anton_z писал(а): 2017.04.12, 03:16 Так я ему говорил, что DTO для вьюшки нужно для снижения зависимости этой вьюшки от всего остального. А он мне говорит "много классов" - плохо, долго вьезжать. Ну я ему на примере модели пытался показать, что "много простых и понятных классов" лучше чем "один божественный". Видать далековато взял)
Очень далековато. Причем так и не поняв сущности моих сообщений.

1. Я не говорил о вреде большого количества классов, я говорил о неразумном размножении классов.
2. Я не говорил что DTO не нужны, а лишь говорил что мапить 1 : 1 шаблоны и DTO это не разумно. DTO объект передачи данных между слоями, так? Так что без проблем разные шаблоны могут юзать один DTO, зависит от слоев.

После опыта проектирования riсh-models, понимаешь что "много простых и понятных классов" не всегда лучше. Но это приходит позже после игр с "архитектурой", "DDD" и "SOLID". :mrgreen:
samdark писал(а): 2017.04.12, 03:01 На какое-то время. Потом возвращаются.
Далеко не факт что возвращаясь используют Yii. Я например переодически открываю форум, читая этот (только) раздел.
Потому что тут весело :) и т.к. для меня единственное место где на русском можно пообщаться, чтоб не забыть его.
Жду Yii 3!
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

Re: Слоистая архитектура для Yii приложений

Сообщение anton_z »

slavcodev писал(а): 2017.04.13, 02:31
Очень далековато. Причем так и не поняв сущности моих сообщений.

1. Я не говорил о вреде большого количества классов, я говорил о неразумном размножении классов.
2. Я не говорил что DTO не нужны, а лишь говорил что мапить 1 : 1 шаблоны и DTO это не разумно. DTO объект передачи данных между слоями, так? Так что без проблем разные шаблоны могут юзать один DTO, зависит от слоев.

После опыта проектирования riсh-models, понимаешь что "много простых и понятных классов" не всегда лучше. Но это приходит позже после игр с "архитектурой", "DDD" и "SOLID". :mrgreen:
Ладно, ладно, не буду спорить)
mitrich
Сообщения: 53
Зарегистрирован: 2012.09.03, 20:57

Re: Слоистая архитектура для Yii приложений

Сообщение mitrich »

Привет.

Возник вопрос на счет события в 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);
		}
	}
Обработка событий у меня пока не вынесена через queue, т. е. все они выполняются по ходу жизни запроса.

Меня смущает тот факт, что когда я вешаю слушатель на это событие, который выполняет отправку во внешний сервис firebase, на внешний socket сервис и т. д., то когда юзер помечает 200 непрочитанных сущностей, - система прилично подвисает.

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

Как тут правильно поступить?

Спасибо.
mitrich
Сообщения: 53
Зарегистрирован: 2012.09.03, 20:57

Re: Слоистая архитектура для Yii приложений

Сообщение mitrich »

Пока что я вижу такой путь. Подключить через 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));
	}
}
На сколько это феншуйно?
Аватара пользователя
ElisDN
Сообщения: 5841
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Слоистая архитектура для Yii приложений

Сообщение ElisDN »

mitrich писал(а): 2018.05.08, 10:02 Как тут правильно поступить?
На будущее всё удобнее вынести в queue.

А пока для экономии можно сделать групповую обработку:

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

$events = [];
foreach ($eventsUsers as $eventUser) {
    $events = array_merge($events, $eventUser->releaseEvents());
}
$this->dispatcher->dispatch([new BatchEvent($events));
Аватара пользователя
yiijeka
Сообщения: 3103
Зарегистрирован: 2012.01.28, 09:14
Откуда: Беларусь
Контактная информация:

Re: Слоистая архитектура для Yii приложений

Сообщение yiijeka »

@mitrich создавайте новую тему, не надо тут задавать вопросы не связанные с обсуждением первого сообщения.
Ответить