Возможно создание репозитория, который имеет операции CRUD по умолчанию. Например:
public interface IRepository<TEntity>
{
TEntity FindByIdentity(object identity);
TEntity FindBy(Expression<Func<TEntity, bool>> specification);
IList<TEntity> FindAll();
IList<TEntity> FindAllBy(Expression<Func<TEntity, bool>> specification);
TEntity Save(TEntity saveable);
void Delete(TEntity deletable);
}
Expression> в основном Спецификация и запросы могут быть инкапсулировать таким образом. Если у нас есть такой репозиторий , нам не нужно писать много конкретных репозиториев.
Альтернативный путь создает Запрос объект. Мы могли бы добавить интерфейс этого запроса к логическому уровню Core/Busines и реализации на уровень Services/Data. Таким образом, у нас есть красиво названные запросы, такие как AllPreferredCustomersQuery. Это очень похоже на спецификации, но спецификации не используют инфраструктуру, и поэтому мы можем добавить ее в уровень Core/Business Logic. Запросы объекты более настраиваемые (например, можно добавить ограничения, стратегии получения, объединения и т. Д.)
Два полезных постов на тему: [Джимми Богард] (http://www.lostechies.com/blogs/jimmy_bogard /archive/2009/09/02/ddd-repository-implementation-patterns.aspx) и [Грег Янг] (http://codebetter.com/blogs/gregyoung/archive/2009/01/16/ddd-the- родовой-repository.aspx). Я тяготею к гибридному подходу: общие хранилища для простых действий и объекты запроса для более сложных. Обычно я не выставляю репозитории для использования моей логики (UI, service), но предлагаю функциональность в шаблоне, подобном сервису/фасаду, поэтому двойной подход не открывается за пределами этого фасадного слоя. – tijmenvdk