DDD хранилища и фабрики - PullRequest
       11

DDD хранилища и фабрики

3 голосов
/ 04 октября 2009

Я прочитал блог о МДД от Мэтта Петтерса

и соответственно и там говорится, что мы создаем репозиторий (интерфейс) для каждой сущности, и после этого мы создаем RepositoryFactory, который собирается давать экземпляры (объявленные как интерфейсы) хранилищ

Это как проект выполняется с использованием DDD?

Я имею в виду, я видел проекты, которые, как мне показалось, используют DDD, но они вызывали каждый репозиторий напрямую, фабрики не было

а также

почему нам нужно создавать так много классов репозитория, почему бы не использовать что-то вроде

public interface IRepository : IDisposable
{
T[] GetAll();
T[] GetAll(Expression<Func> filter); 
T GetSingle(Expression<Func> filter); 
T GetSingle(Expression<Func> filter, List<Expression<Func>> subSelectors); 
void Delete(T entity); 
void Add(T entity); 
int SaveChanges(); 
}

Я думаю, это может быть что-то с нарушением принципов ТВЕРДОГО, или что-то еще?

1 Ответ

6 голосов
/ 04 октября 2009

Есть много разных способов сделать это. Не существует единственного «правильного» способа сделать это. Большинство людей предпочитают репозиторий для каждой сущности, поскольку он позволяет им более детально варьировать доменные службы. Это определенно соответствует 'S' в SOLID.

Когда речь идет о фабриках, их следует использовать только тогда, когда они добавляют стоимость. Если все, что они делают, это оборачивают операцию new, они не добавляют ценность.

Вот несколько сценариев, в которых фабрики увеличивают стоимость:

  • Abtract Factories позволяет варьировать реализации репозитория независимо от клиентского кода. Это хорошо согласуется с буквой «L» в SOLID, но вы также можете добиться того же эффекта, используя DI для внедрения репозитория в доменную службу, которая в этом нуждается.
  • Когда создание объекта само по себе является настолько сложной операцией (т. Е. Включает в себя гораздо больше, чем просто создание нового экземпляра), что его лучше всего инкапсулировать в API.
...