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

Обсуждаем, как правильно строить приложения
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.04.11, 14:00

все равно не уловил связи. ты какую-то другую задачу описываешь.
в данном случае у нас формат dto будет одинаковый, и сигнатура сервиса принимает один dto - нам нет нужды разными параметрами баловаться. Т.е. ты описал 3 кейса, хотя метод будет участвовать только в одном, принимая один формат данных.

Аватара пользователя
rugabarbo
Сообщения: 1061
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

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

Сообщение rugabarbo » 2017.04.11, 14:23

zelenin писал(а):
2017.04.11, 14:00
все равно не уловил связи. ты какую-то другую задачу описываешь.
в данном случае у нас формат dto будет одинаковый, и сигнатура сервиса принимает один dto - нам нет нужды разными параметрами баловаться. Т.е. ты описал 3 кейса, хотя метод будет участвовать только в одном, принимая один формат данных.
Да, криво сформулировал. Я вижу, что многие используют DTO не только по назначению, но ещё и для объединения аргументов вызова методов в один объект. Например, берут в контроллере прямо перед вызовом сервиса инстанцируют DTO, наполняют его и тут же кидают в сервис в качестве аргумента. В таком виде использование DTO есть анти-паттерн. Как мне видится, в таких кейсах программисты пытаются избежать жёсткой привязки к сигнатуре методов сервисов, избежать жёсткого порядка параметров и т.д. Именованные параметры и OptionsResolver как раз помогли бы это сделать и без DTO.

Ну а классическое применение DTO конечно никакими именованными параметрами не заменить. Например, когда его надо вернуть из метода в верхний слой, прокидывать через несколько слоёв или по сети в сериализованном виде.

Возможно мутно изложил, не выспался.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.04.11, 14:35

rugabarbo писал(а):
2017.04.11, 14:23
Да, криво сформулировал. Я вижу, что многие используют DTO не только по назначению, но ещё и для объединения аргументов вызова методов в один объект. Например, берут в контроллере прямо перед вызовом сервиса инстанцируют DTO, наполняют его и тут же кидают в сервис в качестве аргумента. В таком виде использование DTO есть анти-паттерн. Как мне видится, в таких кейсах программисты пытаются избежать жёсткой привязки к сигнатуре методов сервисов, избежать жёсткого порядка параметров и т.д.
не совсем так. этот dto например надо будет провалидировать перед тем как запустить бизнес-процессы в сервисе. Для этого будет существовать например OrderValidator для OrderDto. Иметь в качестве тайп хинта OrderDto удобнее, чем условно 10 параметров в валидаторе и сервисе. Поэтому dto ипользуется как абстракция над пришедшими извне данными, объединенными в одну структуру для удобства работы с сервисном слое - за одной структурой удобнее следить чем за десятью, в т.ч. и при рефакторинге (Find usage).

Аватара пользователя
rugabarbo
Сообщения: 1061
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

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

Сообщение rugabarbo » 2017.04.11, 14:43

Если валидировать, то ОК – в этом случае конечно удобнее DTO, потому что он фигурирует в нескольких местах.

Я лишь против создания DTO в тех местах, где он играет тупую роль группировки аргументов функций. DTO-классов в этом случае получается очень много, а профита очень мало (простое объединение аргументов).

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

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

Сообщение anton_z » 2017.04.11, 15:20

slavcodev писал(а):
2017.04.11, 12:56
Смешались в кучу кони люди.
Если у вас что-то смешалось, это ваша проблема. По-моему здесь все четко.
slavcodev писал(а):
2017.04.11, 12:56
DTO нужны не для того чтоб шаблоны (каждый отдельно шаблон отделить от домена), а для того чтоб отделить два слоя.
Есть DTO для отправки данных в домен. Есть DTO для передачи во VIEW из контроллера. Для чего определим, для того и нужны.

slavcodev писал(а):
2017.04.11, 12:56
Но вот только, делать отдельный ДТО для каждого шаблона, это перебор. Я бы сказал даже что мусор в приложении.
Можно делать, можно не делать. Хотите, чтобы шаблоны были более независимы и переносимы, делайте DTO, не хотите - привязывайте к AR напрямую. В простых приложениях сойдет.
slavcodev писал(а):
2017.04.11, 12:56
Сложность тут не в количестве классов, дело в поддержке.
Ну вот поэтому и полно проектов в которых одна толстая модель AR - это M в MVC (1000+ строк со статическими методами), тонкий контроллер и VIEW, привязанное напрямую к этой жирной модели. "Прекрасное MVC" - по одному классу на слой. Ведь чем меньше классов, тем лучше, понятнее для новичков, верно?)

Аватара пользователя
slavcodev
Сообщения: 3133
Зарегистрирован: 2009.04.02, 21:42
Откуда: Altea, Spain
Контактная информация:

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

Сообщение slavcodev » 2017.04.11, 17:46

anton_z писал(а):
2017.04.11, 15:20
Ну вот поэтому и полно проектов в которых одна толстая модель AR - это M в MVC (1000+ строк со статическими методами), тонкий контроллер и VIEW, привязанное напрямую к этой жирной модели. "Прекрасное MVC" - по одному классу на слой. Ведь чем меньше классов, тем лучше, понятнее для новичков, верно?)
Да именно так и должно быть, толстая модель (не обязательно АР) и тонкий контролер.
Жду Yii 3!

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

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

Сообщение ElisDN » 2017.04.11, 20:07

slavcodev писал(а):
2017.04.11, 17:46
Да именно так и должно быть, толстая модель (не обязательно АР) и тонкий контролер.
Это уже "жирная", а не "толстая" :)

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

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

Сообщение anton_z » 2017.04.12, 00:42

slavcodev писал(а):
2017.04.11, 17:46
anton_z писал(а):
2017.04.11, 15:20
Ну вот поэтому и полно проектов в которых одна толстая модель AR - это M в MVC (1000+ строк со статическими методами), тонкий контроллер и VIEW, привязанное напрямую к этой жирной модели. "Прекрасное MVC" - по одному классу на слой. Ведь чем меньше классов, тем лучше, понятнее для новичков, верно?)
Да именно так и должно быть, толстая модель (не обязательно АР) и тонкий контролер.
Улыбнуло) Это был сарказм) Ну вот отсюда и все проблемы. Непонимание MVC. Где там сказано про один класс на слой? Так только в yii и ror думают)
Последний раз редактировалось anton_z 2017.04.12, 02:30, всего редактировалось 1 раз.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.04.12, 01:17

anton_z писал(а):
2017.04.12, 00:42
slavcodev писал(а):
2017.04.11, 17:46
anton_z писал(а):
2017.04.11, 15:20
Ну вот поэтому и полно проектов в которых одна толстая модель AR - это M в MVC (1000+ строк со статическими методами), тонкий контроллер и VIEW, привязанное напрямую к этой жирной модели. "Прекрасное MVC" - по одному классу на слой. Ведь чем меньше классов, тем лучше, понятнее для новичков, верно?)
Да именно так и должно быть, толстая модель (не обязательно АР) и тонкий контролер.
Улыбнуло) Это был сарказм) Ну вот отсюда и все проблемы. Непонимание MVC. Где там сказано про один класс на слой? Так только в yii и ror думают) И это был сарказм)
Антон, как раз это ты неправильно интерпретировал M из MVC как толстую AR-модель со статическиим методами. slavcodev прекрасно понимает, что модель MVC - это бизнес-слой/слой данных в общем, и, да, этот слой должен быть толстым.
M - это не класс. M - это слой.

Аватара пользователя
rugabarbo
Сообщения: 1061
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

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

Сообщение rugabarbo » 2017.04.12, 01:31

zelenin писал(а):
2017.04.12, 01:17
M - это не класс. M - это слой.
Кстати, меня из-за этого класс Model в Yii раздражает: http://www.yiiframework.com/doc-2.0/yii-base-model.html - его название вводит в заблуждение.

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

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

Сообщение anton_z » 2017.04.12, 02:33

zelenin писал(а):
2017.04.12, 01:17
Антон, как раз это ты неправильно интерпретировал M из MVC как толстую AR-модель со статическиим методами. slavcodev прекрасно понимает, что модель MVC - это бизнес-слой/слой данных в общем, и, да, этот слой должен быть толстым.
M - это не класс. M - это слой.
Я ж говорю, это сарказм) Конечно M это слой. Я пытался slavcodev доказать, что "больше классов" это в большинстве случаев лучше чем "одна божественная AR" в которую заткнут весь слой M и на которую завязано все приложение.

Аватара пользователя
rugabarbo
Сообщения: 1061
Зарегистрирован: 2015.06.21, 16:21
Контактная информация:

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

Сообщение rugabarbo » 2017.04.12, 02:41

По теме: интересный-таки вот этот момент, когда Yii-разработчик дорастает до "слоистой архитектуры поверх AR". Ведь следующим откровением обычно становится: "мне не нужен AR" - а за ним: "мне не нужен Yii?!!" - и дальше вопрос встаёт лишь за достаточным количеством времени, чтобы пересесть на другой немонолитный стэк.

Эдакий кризис роста, после которого люди пропадают из сообщества Yii.
Последний раз редактировалось rugabarbo 2017.04.12, 02:42, всего редактировалось 1 раз.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.04.12, 02:42

anton_z писал(а):
2017.04.12, 02:33
zelenin писал(а):
2017.04.12, 01:17
Антон, как раз это ты неправильно интерпретировал M из MVC как толстую AR-модель со статическиим методами. slavcodev прекрасно понимает, что модель MVC - это бизнес-слой/слой данных в общем, и, да, этот слой должен быть толстым.
M - это не класс. M - это слой.
Я ж говорю, это сарказм) Конечно M это слой. Я пытался slavcodev доказать, что "больше классов" это в большинстве случаев лучше чем "одна божественная AR" в которую заткнут весь слой M и на которую завязано все приложение.
а он и не утверждал обратного

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

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

Сообщение samdark » 2017.04.12, 03:01

люди пропадают из сообщества Yii.
На какое-то время. Потом возвращаются. Наигравшись в архитектуру начинаешь понимать, что тот же DDD... да что DDD, Data Mapper — не оптимальное решение для большинства проектов. Оно там просто не надо и излишне. Из всего множества проектов до необходимости сложной архитектуры без монолита дорастает максимум процентов 10 проектов. Остальные или умирают по дороге по не техническим причинам или нормально живут и развиваются в виде монолита или почти монолита (тот же Stay.com).

А вообще Yii я планирую делать всё менее монолитным (где это имеет смысл) от версии к версии. Кое-что попиливаю. Должно получиться.

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

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

Сообщение anton_z » 2017.04.12, 03:10

slavcodev писал(а):
2017.04.11, 12:56
- Новичкам въехать и запомнить каждый класс + к проблемам.
- В больших командах и большим приложением, не уследишь за изменениями а реакция на изменения в индустрии должны отражаться в приложении мгновенно, не когда разбираться и кучи лишних "простых классах"
zelenin писал(а):
2017.04.12, 02:42
а он и не утверждал обратного

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

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

Сообщение anton_z » 2017.04.12, 03:13

samdark писал(а):
2017.04.12, 03:01
На какое-то время. Потом возвращаются.
Но их код на Yii уже никогда не будет прежним. По-другому будут писать совсем, думая об архитектуре и зная слабые стороны фреймворка.
Последний раз редактировалось anton_z 2017.04.12, 03:13, всего редактировалось 2 раза.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

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

Сообщение zelenin » 2017.04.12, 03:13

anton_z писал(а):
2017.04.12, 03:10
slavcodev писал(а):
2017.04.11, 12:56
- Новичкам въехать и запомнить каждый класс + к проблемам.
- В больших командах и большим приложением, не уследишь за изменениями а реакция на изменения в индустрии должны отражаться в приложении мгновенно, не когда разбираться и кучи лишних "простых классах"
zelenin писал(а):
2017.04.12, 02:42
а он и не утверждал обратного
вы дто для каждой вьюшки обсуждали, а не толстую модель.

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

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

Сообщение anton_z » 2017.04.12, 03:16

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

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

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

Сообщение anton_z » 2017.04.12, 04:10

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

Я так понял, что под DataMapper вы имеете ввиду Docrine или Hibernate? DM бывают разные:
https://en.wikipedia.org/wiki/Data_mapper_pattern. Простые и сложные.
Его можно рассматривать как простой паттерн преобразования данных из БД в объекты, представляющие единицы данных в БД.
В Doctrine еще гора всего есть: DQL, UoW, IdentityMap, LazyLoad, InheritanceMapping и прочее. Я бы сказал, что такие ORM это не DataMapper, а "вещи в себе".

Сравните:

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


$row = $gateway->get($id);

$row->changeSomething($arg);

$geteway->update($row);

Внутри шлюза есть mapper, который преобразует данные из БД в php, де/сериализует LOB и прочее.

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


$ar = SomeActiveRecordClass::find($id);

$ar->doSomething();

$ar->save();

Что сложнее? Что из этого является тестируемым, а что нет? Где SOLID соблюдается? В yii, кстати, второе легко делается при помощи DAO. Единственное, что теряем - отображение связей и lazy load. Однако, без этого в определенных пределах можно обойтись, получая данные из других шлюзов явно в коде сервисов по внешним ключам. Основная часть межмодельной бизнес-логики при этом уедет в сервисы. Но это не проблема, если ее не много. Если этого будет мало, всегда можно дополнить такую реализацию отображением связей и lazy-load по статьям ElisDN.

Да и в той же Doctrine скорость разработки не сильно от AR отличается. А если нужны модульные тесты (с AR приходится извращаться: инжектить их, фабрики делать, чтобы мокать можно было, и то это не всегда возможно и не получается), то и обгоняет. TDD на проекты с DataMapper лучше ложится.

Да, если делать простые сайты без модульных тестов, обходясь приемочными тестами или вообще без них (как большинство и делает) - выигрыш в скорости начальной разработки с AR будет. Конечно, в процессе развития (если таковое будет), потом придется поплакать. Если так работать, то да, AR лучше. Однако, в таком классе проектов есть соблазн ускориться еще больше и уйти на какую-нибудь хорошую CMS.

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

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

Сообщение samdark » 2017.04.12, 12:46

Ясно, что есть мапперы-монстры и мапперы попроще. Из коробки (пока) маппера нет, но удобный AR есть. И да, не надо большинству потому что к AR все привыкли. Когда будет маппер из коробки с чем-то, что по удобству будет как relations а AR — все без проблем перепрыгнут на маппер.

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

Ответить