Слоистая архитектура для Yii приложений
Re: Слоистая архитектура для Yii приложений
все равно не уловил связи. ты какую-то другую задачу описываешь.
в данном случае у нас формат dto будет одинаковый, и сигнатура сервиса принимает один dto - нам нет нужды разными параметрами баловаться. Т.е. ты описал 3 кейса, хотя метод будет участвовать только в одном, принимая один формат данных.
в данном случае у нас формат dto будет одинаковый, и сигнатура сервиса принимает один dto - нам нет нужды разными параметрами баловаться. Т.е. ты описал 3 кейса, хотя метод будет участвовать только в одном, принимая один формат данных.
Re: Слоистая архитектура для Yii приложений
Да, криво сформулировал. Я вижу, что многие используют DTO не только по назначению, но ещё и для объединения аргументов вызова методов в один объект. Например, берут в контроллере прямо перед вызовом сервиса инстанцируют DTO, наполняют его и тут же кидают в сервис в качестве аргумента. В таком виде использование DTO есть анти-паттерн. Как мне видится, в таких кейсах программисты пытаются избежать жёсткой привязки к сигнатуре методов сервисов, избежать жёсткого порядка параметров и т.д. Именованные параметры и OptionsResolver как раз помогли бы это сделать и без DTO.zelenin писал(а): ↑2017.04.11, 14:00 все равно не уловил связи. ты какую-то другую задачу описываешь.
в данном случае у нас формат dto будет одинаковый, и сигнатура сервиса принимает один dto - нам нет нужды разными параметрами баловаться. Т.е. ты описал 3 кейса, хотя метод будет участвовать только в одном, принимая один формат данных.
Ну а классическое применение DTO конечно никакими именованными параметрами не заменить. Например, когда его надо вернуть из метода в верхний слой, прокидывать через несколько слоёв или по сети в сериализованном виде.
Возможно мутно изложил, не выспался.
Re: Слоистая архитектура для Yii приложений
не совсем так. этот dto например надо будет провалидировать перед тем как запустить бизнес-процессы в сервисе. Для этого будет существовать например OrderValidator для OrderDto. Иметь в качестве тайп хинта OrderDto удобнее, чем условно 10 параметров в валидаторе и сервисе. Поэтому dto ипользуется как абстракция над пришедшими извне данными, объединенными в одну структуру для удобства работы с сервисном слое - за одной структурой удобнее следить чем за десятью, в т.ч. и при рефакторинге (Find usage).rugabarbo писал(а): ↑2017.04.11, 14:23Да, криво сформулировал. Я вижу, что многие используют DTO не только по назначению, но ещё и для объединения аргументов вызова методов в один объект. Например, берут в контроллере прямо перед вызовом сервиса инстанцируют DTO, наполняют его и тут же кидают в сервис в качестве аргумента. В таком виде использование DTO есть анти-паттерн. Как мне видится, в таких кейсах программисты пытаются избежать жёсткой привязки к сигнатуре методов сервисов, избежать жёсткого порядка параметров и т.д.
Re: Слоистая архитектура для Yii приложений
Если валидировать, то ОК – в этом случае конечно удобнее DTO, потому что он фигурирует в нескольких местах.
Я лишь против создания DTO в тех местах, где он играет тупую роль группировки аргументов функций. DTO-классов в этом случае получается очень много, а профита очень мало (простое объединение аргументов).
Я лишь против создания DTO в тех местах, где он играет тупую роль группировки аргументов функций. DTO-классов в этом случае получается очень много, а профита очень мало (простое объединение аргументов).
Re: Слоистая архитектура для Yii приложений
Если у вас что-то смешалось, это ваша проблема. По-моему здесь все четко.
Есть DTO для отправки данных в домен. Есть DTO для передачи во VIEW из контроллера. Для чего определим, для того и нужны.
Можно делать, можно не делать. Хотите, чтобы шаблоны были более независимы и переносимы, делайте DTO, не хотите - привязывайте к AR напрямую. В простых приложениях сойдет.
Ну вот поэтому и полно проектов в которых одна толстая модель AR - это M в MVC (1000+ строк со статическими методами), тонкий контроллер и VIEW, привязанное напрямую к этой жирной модели. "Прекрасное MVC" - по одному классу на слой. Ведь чем меньше классов, тем лучше, понятнее для новичков, верно?)
- slavcodev
- Сообщения: 3134
- Зарегистрирован: 2009.04.02, 21:42
- Откуда: Valencia
- Контактная информация:
Re: Слоистая архитектура для Yii приложений
Да именно так и должно быть, толстая модель (не обязательно АР) и тонкий контролер.anton_z писал(а): ↑2017.04.11, 15:20 Ну вот поэтому и полно проектов в которых одна толстая модель AR - это M в MVC (1000+ строк со статическими методами), тонкий контроллер и VIEW, привязанное напрямую к этой жирной модели. "Прекрасное MVC" - по одному классу на слой. Ведь чем меньше классов, тем лучше, понятнее для новичков, верно?)
Жду Yii 3!
Re: Слоистая архитектура для Yii приложений
Улыбнуло) Это был сарказм) Ну вот отсюда и все проблемы. Непонимание MVC. Где там сказано про один класс на слой? Так только в yii и ror думают)slavcodev писал(а): ↑2017.04.11, 17:46Да именно так и должно быть, толстая модель (не обязательно АР) и тонкий контролер.anton_z писал(а): ↑2017.04.11, 15:20 Ну вот поэтому и полно проектов в которых одна толстая модель AR - это M в MVC (1000+ строк со статическими методами), тонкий контроллер и VIEW, привязанное напрямую к этой жирной модели. "Прекрасное MVC" - по одному классу на слой. Ведь чем меньше классов, тем лучше, понятнее для новичков, верно?)
Последний раз редактировалось anton_z 2017.04.12, 02:30, всего редактировалось 1 раз.
Re: Слоистая архитектура для Yii приложений
Антон, как раз это ты неправильно интерпретировал M из MVC как толстую AR-модель со статическиим методами. slavcodev прекрасно понимает, что модель MVC - это бизнес-слой/слой данных в общем, и, да, этот слой должен быть толстым.anton_z писал(а): ↑2017.04.12, 00:42Улыбнуло) Это был сарказм) Ну вот отсюда и все проблемы. Непонимание MVC. Где там сказано про один класс на слой? Так только в yii и ror думают) И это был сарказм)slavcodev писал(а): ↑2017.04.11, 17:46Да именно так и должно быть, толстая модель (не обязательно АР) и тонкий контролер.anton_z писал(а): ↑2017.04.11, 15:20 Ну вот поэтому и полно проектов в которых одна толстая модель AR - это M в MVC (1000+ строк со статическими методами), тонкий контроллер и VIEW, привязанное напрямую к этой жирной модели. "Прекрасное MVC" - по одному классу на слой. Ведь чем меньше классов, тем лучше, понятнее для новичков, верно?)
M - это не класс. M - это слой.
Re: Слоистая архитектура для Yii приложений
Кстати, меня из-за этого класс Model в Yii раздражает: http://www.yiiframework.com/doc-2.0/yii-base-model.html - его название вводит в заблуждение.
Re: Слоистая архитектура для Yii приложений
Я ж говорю, это сарказм) Конечно M это слой. Я пытался slavcodev доказать, что "больше классов" это в большинстве случаев лучше чем "одна божественная AR" в которую заткнут весь слой M и на которую завязано все приложение.
Re: Слоистая архитектура для Yii приложений
По теме: интересный-таки вот этот момент, когда Yii-разработчик дорастает до "слоистой архитектуры поверх AR". Ведь следующим откровением обычно становится: "мне не нужен AR" - а за ним: "мне не нужен Yii?!!" - и дальше вопрос встаёт лишь за достаточным количеством времени, чтобы пересесть на другой немонолитный стэк.
Эдакий кризис роста, после которого люди пропадают из сообщества Yii.
Эдакий кризис роста, после которого люди пропадают из сообщества Yii.
Последний раз редактировалось rugabarbo 2017.04.12, 02:42, всего редактировалось 1 раз.
Re: Слоистая архитектура для Yii приложений
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Слоистая архитектура для Yii приложений
На какое-то время. Потом возвращаются. Наигравшись в архитектуру начинаешь понимать, что тот же DDD... да что DDD, Data Mapper — не оптимальное решение для большинства проектов. Оно там просто не надо и излишне. Из всего множества проектов до необходимости сложной архитектуры без монолита дорастает максимум процентов 10 проектов. Остальные или умирают по дороге по не техническим причинам или нормально живут и развиваются в виде монолита или почти монолита (тот же Stay.com).люди пропадают из сообщества Yii.
А вообще Yii я планирую делать всё менее монолитным (где это имеет смысл) от версии к версии. Кое-что попиливаю. Должно получиться.
Нравится Yii? Давайте сделаем его лучше!.
Re: Слоистая архитектура для Yii приложений
Но их код на Yii уже никогда не будет прежним. По-другому будут писать совсем, думая об архитектуре и зная слабые стороны фреймворка.
Последний раз редактировалось anton_z 2017.04.12, 03:13, всего редактировалось 2 раза.
Re: Слоистая архитектура для Yii приложений
Re: Слоистая архитектура для Yii приложений
Так я ему говорил, что DTO для вьюшки нужно для снижения зависимости этой вьюшки от всего остального. А он мне говорит "много классов" - плохо, долго вьезжать. Ну я ему на примере модели пытался показать, что "много простых и понятных классов" лучше чем "один божественный". Видать далековато взял)
Re: Слоистая архитектура для Yii приложений
Про 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);
Код: Выделить всё
$ar = SomeActiveRecordClass::find($id);
$ar->doSomething();
$ar->save();
Да и в той же Doctrine скорость разработки не сильно от AR отличается. А если нужны модульные тесты (с AR приходится извращаться: инжектить их, фабрики делать, чтобы мокать можно было, и то это не всегда возможно и не получается), то и обгоняет. TDD на проекты с DataMapper лучше ложится.
Да, если делать простые сайты без модульных тестов, обходясь приемочными тестами или вообще без них (как большинство и делает) - выигрыш в скорости начальной разработки с AR будет. Конечно, в процессе развития (если таковое будет), потом придется поплакать. Если так работать, то да, AR лучше. Однако, в таком классе проектов есть соблазн ускориться еще больше и уйти на какую-нибудь хорошую CMS.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Слоистая архитектура для Yii приложений
Ясно, что есть мапперы-монстры и мапперы попроще. Из коробки (пока) маппера нет, но удобный AR есть. И да, не надо большинству потому что к AR все привыкли. Когда будет маппер из коробки с чем-то, что по удобству будет как relations а AR — все без проблем перепрыгнут на маппер.
В примере выше сложнее, конечно же, маппер. Сущностей больше, а наш мозг привык оперировать как можно меньшим их количеством. Если тестировать всё и много, естественно, сложность эта оправдана — будет экономия на тестах.
В примере выше сложнее, конечно же, маппер. Сущностей больше, а наш мозг привык оперировать как можно меньшим их количеством. Если тестировать всё и много, естественно, сложность эта оправдана — будет экономия на тестах.
Нравится Yii? Давайте сделаем его лучше!.