Страница 5 из 5

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

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

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

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

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

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

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

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

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

Но проблема в том, что мало кто умеет писать так, чтобы не зависеть от Yii (ну, я по крайней мере не на 100% это пока умею).

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

Добавлено: 2017.04.12, 14:10
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

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

Добавлено: 2017.04.12, 14:11
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-решением.
присоединяюсь. Только в качестве первопричины первого назвал бы не время и деньги, а талант, опыт, обучаемость, желание научиться. Время и деньги - это скорее производные.

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

Добавлено: 2017.04.12, 14:14
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 не вписывается.

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

Добавлено: 2017.04.12, 14:19
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 это дубль одного слоя.

Согласен, от избытка информации не всегда улавливаешь основную простую суть. Пдскажите?

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

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

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

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

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

Добавлено: 2017.04.12, 22:42
rugabarbo
Можно тестировать и монолитный код. Просто это больно.
По крайнее мере больнее тестирования компонентного/слоёного.

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

Добавлено: 2017.04.13, 02:31
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. Я например переодически открываю форум, читая этот (только) раздел.
Потому что тут весело :) и т.к. для меня единственное место где на русском можно пообщаться, чтоб не забыть его.

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

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

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

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

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

Добавлено: 2018.05.08, 10:02
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 коннектов/дисконнектов на внешний сервис.

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

Спасибо.

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

Добавлено: 2018.05.08, 10:41
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));
	}
}
На сколько это феншуйно?

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

Добавлено: 2018.05.08, 10:46
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));

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

Добавлено: 2018.07.27, 11:43
yiijeka
@mitrich создавайте новую тему, не надо тут задавать вопросы не связанные с обсуждением первого сообщения.