Вы теряете способность иметь бизнес-логику между ними.
Я не согласен с этим.
Если бизнес-логика там, где она должна быть - в доменной модели, то вызов репо в контроллере (или лучше - использовать связыватель модели) для получения агрегированного корня и вызова метода для него кажется мне вполне подходящим.
Прикладные службы должны использоваться, когда слишком много технических деталей связано с тем, что может испортить контроллеры.
Я видел, как несколько человек упоминали об использовании связующих моделей для вызова в репонедавно.Откуда взялась эта безумная идея?
Я думаю, что мы говорим здесь о двух разных вещах.Я подозреваю, что «связыватель модели» означает одновременное использование модели в качестве модели представления и привязку измененных значений непосредственно из интерфейса непосредственно к ней (что само по себе неплохо, и в некоторых случаях я бы пошел этим путем).
Мой связыватель моделей - это класс, который реализует IModelBinder , который принимает репозиторий в конструкторе (который внедряется и, следовательно, - может быть расширен, если нам нужно кэширование с некоторым базовым составом) и используетперед вызовом действия для извлечения совокупного корня и замены аргумента действия int id или Guid id или string slug или whatever реальным объектом домена.Объединяя это с аргументом модели представления ввода, мы можем писать меньше кода.Примерно так:
public ActionResult ChangeCustomerAddress
(Customer c, ChangeCustomerAddressInput inp){
c.ChangeCustomerAddress(inp.NewAddress);
return RedirectToAction("Details", new{inp.Id});
}
В моем реальном коде это немного сложнее, поскольку включает проверку ModelState и некоторую обработку исключений, которые могут быть выброшены изнутри модели домена (извлечены в метод расширения Controller для повторного использования).Но не намного.Пока что самое длинное действие контроллера составляет ~ 10 строк.
Вы можете увидеть работающую реализацию (довольно сложную и (для меня) ненужную сложность) здесь .
Вы просто делаете CRUD-приложения с Linq To Sql или пробуете что-то с реальной доменной логикой?
Как вы можете (надеюсь) увидеть, такой подход фактически заставляет нас двигаться к * основанное на задачах приложение вместо CRUD-приложения.
Делая весь доступ к данным на уровне сервисов и используя IOC, вы можете получить множество преимуществ AOP, таких как невидимое кэширование, управление транзакциями и простотасостав компонентов, которые я не могу себе представить, вы получите с помощью связывателей моделей.
... и с новым уровнем абстракции, который предлагает нам смешивать инфраструктуру с логикой домена и терять изоляциюмодели домена.
Пожалуйста, просветите меня.
Я не уверен, что сделал.Я не думаю, что я сам просветленный.:)
Здесь - базовый класс моей связующей модели. Вот одно из действий контроллера из моего текущего проекта.И вот «недостаток» бизнес-логики.