Вопросы относительно Домена управляемый Дизайн
Можно также добавить эту команду к контекстному меню с маленьким сценарием...
редактирование : о, извините. не сделал видел, что это было уже предложено...
3 ответа
Существует много споров о том, должны ли репозитории быть доступными только для чтения или разрешать транзакции. DDD не диктует никаких из этих взглядов. Вы можете сделать и то, и другое. Сторонники репозиториев только для чтения предпочитают Unit of Work для всех операций CUD.
Большинство людей (включая себя) считают хорошей практикой то, что сущности являются постоянными-невежественными. Небольшое расширение этого принципа укажет на то, что они должны быть автономными и свободными от всех служб уровня инфраструктуры - даже в абстрактной форме. Поэтому я бы сказал, что вызовы инфраструктурных сервисов принадлежат классам сервисов, которые работают с сущностями.
Кажется правильным, что реализации репозитория и фабрики (если таковые имеются) должны находиться на уровне инфраструктуры. Однако их интерфейсы должны находиться на уровне домена, чтобы службы домена могли взаимодействовать с ними без зависимости от уровня инфраструктуры.
DDD на самом деле не диктует, можно ли пропускать слои или нет. В конце книги Эванс немного говорит о наслоении и называет его расслабленным наслоением, если вы позволяете это, так что я думаю, он просто рассматривает это как один из нескольких вариантов. Лично я бы предпочел предотвратить пропуск слоев, потому что это упрощает внедрение некоторого поведения в будущем, если вызовы уже проходят через правильные уровни.
Репозиторий должен использоваться только для поиска и сохранения сущностей, на этом уровне не должно быть никакой бизнес-логики. Например:
репозиторий.TransferAmount (сумма, toAccount); // это плохо
Сущности могут делать такие вещи, как отправка электронных писем, если они зависят от абстракций, определенных в вашем домене. Реализация должна быть на уровне вашей инфраструктуры.
Да, вы помещаете реализацию репозитория на уровень инфраструктуры.
Может ли уровень пользовательского интерфейса (контроллер) вызывать методы репозитория напрямую? или мы должны вызывать их из уровня приложения?
Да, я стараюсь по большей части следовать этому шаблону:
[UnitOfWork]
public ActionResult MyControllerAction(int id)
{
var entity = repository.FindById(id);
entity.DoSomeBusinessLogic();
repository.Update(entity);
}
Personally, in my latest DDD-project, I use a Unit Of Work that holds an NHibernate session. The UoW is ctor injected in the repositories, giving them the single responsible of Add, Remove and Find.
Evans has stated that one piece of the puzzle that's missing in the DDD book is «Domain Events». Using something like Udi Dahan's DomainEvents will give you a totally decoupled architecture (the domain object simply raises an event). Personally, I use a modified version of Domain Events and StructureMap for the wiring. It works great for my needs.
I recommend, based on other recommendations, that the Repository interfaces be a part of the model, and their implementations be a part of the infrastructure.
Yes! I've personally worked on three DDD web projects where services and repositories were injected to the presenters/controllers (ASP.NET/ASP.NET MVC) and it made a lot of sense in our context.