Найдено 3120 результатов

slavcodev
2017.04.19, 23:29
Форум: Архитектура, дизайн, ООП
Тема: Вопросы по ViewModel
Ответы: 22
Просмотры: 5620

Re: Вопросы по ViewModel

То есть условно на запрос пользователя ему нужно вернуть ответ {login: 'name', money: 100}, а всем остальным уведомление {login: 'name'}. Но я не могу из сервиса вернуть два разных dto. Теперь я вообще не знаю, что я должен возвращать из сервиса. Пусть возвращают DTO содержащий данные на "все кейсы...
slavcodev
2017.04.19, 23:25
Форум: Архитектура, дизайн, ООП
Тема: Вопросы по ViewModel
Ответы: 22
Просмотры: 5620

Re: Вопросы по ViewModel

sda писал(а):
2017.03.22, 15:36
3. Application service может возвращать в контроллер доменный объект ?
Не может. Контроллер это UI, ничего о домене он знать не должен.
slavcodev
2017.04.19, 19:08
Форум: Архитектура, дизайн, ООП
Тема: DI в DDD проектах
Ответы: 30
Просмотры: 5767

Re: DI в DDD проектах

Более склоняюсь к использованию контейнера именно как контейнера stateless сервисов-синглтонов c $container->get($id), а не как фабрику для клепания на лету новых инстансов по примеру Yii. В возврате новых инстансов для таких сервисов нет смысла. А если нужно клепать динамически инстансы как в фабр...
slavcodev
2017.04.17, 17:24
Форум: Архитектура, дизайн, ООП
Тема: Проектирование сущностей, сервисов и репозиториев
Ответы: 108
Просмотры: 23897

Re: Проектирование сущностей, сервисов и репозиториев

Есть хорошие практики, любой патерн из категории Creational patterns
slavcodev
2017.04.13, 02:31
Форум: Архитектура, дизайн, ООП
Тема: Слоистая архитектура для Yii приложений
Ответы: 95
Просмотры: 22447

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

Так я ему говорил, что DTO для вьюшки нужно для снижения зависимости этой вьюшки от всего остального. А он мне говорит "много классов" - плохо, долго вьезжать. Ну я ему на примере модели пытался показать, что "много простых и понятных классов" лучше чем "один божественный". Видать далековато взял) ...
slavcodev
2017.04.11, 17:46
Форум: Архитектура, дизайн, ООП
Тема: Слоистая архитектура для Yii приложений
Ответы: 95
Просмотры: 22447

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

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

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

Создать два простых класса это ой как сложно, прям капец) Тут все дело в зависимостях. Отдельные DTO для шаблонов нужны для того, чтобы снизить зависимость шаблонов от домена. (VIEW от MODEL в MVC) Используя отдельный DTO, будет очень легко заменить User на какую-то другую DTO или сущность, два, тр...
slavcodev
2017.04.11, 04:29
Форум: Архитектура, дизайн, ООП
Тема: Слоистая архитектура для Yii приложений
Ответы: 95
Просмотры: 22447

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

1) DTO - объект данных передающийся между слоями. Создавать его в контролере, в Presentation Layer (т.е. самом крайнем) безполезно. Скорее всего это ДТО должен возвращаться из сервисов. А что предлагаете вместов него? AR? Форму с горой зависимостей в сервис отдавать? Я ничего не говорил о том что в...
slavcodev
2017.04.06, 16:52
Форум: Архитектура, дизайн, ООП
Тема: А что вы делаете с дублированием кода в Application Service?
Ответы: 19
Просмотры: 3803

Re: А что вы делаете с дублированием кода в Application Service?

Лучше иметь один репозиторий и два метода, по одному на диктуемую доменом условие, а не дублировать проверки в сервисах.
slavcodev
2017.04.06, 14:00
Форум: Архитектура, дизайн, ООП
Тема: Слоистая архитектура для Yii приложений
Ответы: 95
Просмотры: 22447

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

Добавлю свои пять копеек 1) DTO - объект данных передающийся между слоями. Создавать его в контролере, в Presentation Layer (т.е. самом крайнем) безполезно. Скорее всего это ДТО должен возвращаться из сервисов. 2) Декораторы над DTO? Для чего это может быть полезно? 3) Generic DTO + костыльные декор...
slavcodev
2017.04.06, 13:10
Форум: Архитектура, дизайн, ООП
Тема: А что вы делаете с дублированием кода в Application Service?
Ответы: 19
Просмотры: 3803

Re: А что вы делаете с дублированием кода в Application Service?

Мне кажется, ни документация, ни название метода не остановят человека от ошибки Человека воообще мало что останавливает, учитывая текущее состоянии мира. К тому же, учитывая кол-во проверок/исключений, может случится так, что либо будет много высокоспецифичных методов у репозитория, либо ее вовсе ...
slavcodev
2017.04.05, 19:28
Форум: Архитектура, дизайн, ООП
Тема: А что вы делаете с дублированием кода в Application Service?
Ответы: 19
Просмотры: 3803

Re: А что вы делаете с дублированием кода в Application Service?

Хотя реализация "дело вкуса" и может не зависеть от инфраструктуры, я имел виду именно интерфейс репозитория. Если интерфейс утверждает что будет получен именно незабаненный юзер, значит любая реализация должна реализовывать этот интерфейс. Я привел пример с часто существующем "getById" (ну или как ...
slavcodev
2017.04.05, 16:53
Форум: Архитектура, дизайн, ООП
Тема: А что вы делаете с дублированием кода в Application Service?
Ответы: 19
Просмотры: 3803

Re: А что вы делаете с дублированием кода в Application Service?

Репозиторий - часть домен, не инфраструктуры. Я в том смысле, что если решим переписать репозиторий, например под другое хранилище, можем забыть про то, чтобы бросать данное исключение. Звучит странно для меня. Точно так же можно "забыть" методом "getById" вернуть сущность с нужным ИД. Репозиторий э...
slavcodev
2017.04.05, 02:24
Форум: Архитектура, дизайн, ООП
Тема: А что вы делаете с дублированием кода в Application Service?
Ответы: 19
Просмотры: 3803

Re: А что вы делаете с дублированием кода в Application Service?

Или можно во всех сервисах у репозитория запросить "незабанненого" юзера по ИД и в репозитории кидать оба исключения по необходимости.
slavcodev
2016.12.26, 14:41
Форум: Архитектура, дизайн, ООП
Тема: Вопросы по существу по DDD
Ответы: 25
Просмотры: 4826

Re: Вопросы по существу по DDD

Сори, промахнулся, вопрос больше наверное к slavcodev. Т.к. он написал, что для DTO неважно в какой слой прилетать. Как по мне, если DTO в сущности передавать, то тогда эти DTO придется перетащить в доменный слой. Что не совсем гуд. DTO - я считаю просто массив данных представленный объектом. Для ч...
slavcodev
2016.12.23, 01:44
Форум: Архитектура, дизайн, ООП
Тема: Вопросы по существу по DDD
Ответы: 25
Просмотры: 4826

Re: Вопросы по существу по DDD

не верно. DTO просто выполняет служебные функции в контексте приложения (app layer) для переноса данных между реквестом и и сервисом в общем случае Понятно. А где DTO должна "теряться"? К примеру, прилетает в контроллер, мы далее передаем DTO-ку в вызываемый сервис. Вот там получается из DTO извлек...
slavcodev
2016.10.17, 23:49
Форум: Архитектура, дизайн, ООП
Тема: Dependency Injection, DIC и Service Locator
Ответы: 8
Просмотры: 3405

Re: Dependency Injection, DIC и Service Locator

Sam Dark писал(а):Впилить её в свой проект не сложно: https://github.com/SAM-IT/yii2-magic/bl ... nTrait.php
Угу. В принципе не сложно заменить Yii на любой другой фреймворк :mrgreen:
Вопрос в целесообразности тех или иных изменений в Yii.
slavcodev
2016.10.12, 19:50
Форум: Архитектура, дизайн, ООП
Тема: Specification pattern
Ответы: 69
Просмотры: 10069

Re: Specification pattern

zelenin писал(а):Мы составляем Query, передаем его в репозиторий, который является query executor.
Вот это я и называю выход за пределы домена. Если ты query собираешь за пределами репозитория и посылаешь его параметром в него, это за пределами домена.
slavcodev
2016.10.12, 17:27
Форум: Архитектура, дизайн, ООП
Тема: Specification pattern
Ответы: 69
Просмотры: 10069

Re: Specification pattern

Если я правильно понял, то что zelenin предложил , не является на самом деле QueryObject, думаю просто название не верное выбрал, какой-нибудь PostSpecification наверное бы меньше путаницы бы внес. Хотя я по прежнему думаю такой билдер выносить за переделы имплементации доменной модели, не очень удо...