2

У меня вопрос. мы используем общий репозиторий, и наша модель домена также является моделью персистентности, но это заставило нас модифицировать нашу модель домена, чтобы быть согласованной с ORM, например: - мы должны поместить частный конструктор по умолчанию и некоторые другие грязные мы используем (в данном случае, Entity Framework), и теперь мы решаем иметь модель персистентности, которая отличается от нашей богатой модели домена, но мы не можем использовать Generic Repository в этом случае. Примечание: - Мы создаем наши модели для создания наших доменных моделей, но мы используем AutoMapper для преобразования из моделей доменов в модель Persistence.Как использовать общий репозиторий с DDD (модель домена + модель сохранения)?

+0

* «мы не можем использовать общий репозиторий в данном случае» * - почему? И зачем вам это нужно в первую очередь? – guillaume31

+0

Привет, мне нужно упростить процесс разработки – roro2012

+0

Мне не нужно повторять один и тот же код в каждом репозитории – roro2012

ответ

3

Это сложный вопрос, потому что вы пытаетесь примирить два антагонистических подхода к упорству в DDD, которые были разработаны противоположными школами мысли.

Общий шаблон репозитория, рассмотренный некоторыми как antipattern, относится к раннему внедрению DDD, когда люди находились в поисках инструментов и методов для упрощения настойчивости в системах DDD. Большинство реализаций в конечном итоге подвергли специфике запросов ORM (в случае Entity Framework) в контракте общего хранилища, поскольку они были удобной общей почтой между всеми видами вещей, которые вы могли бы запросить у репо.

Более поздний подход к модели сохранения устойчивости - это шаг в противоположном направлении - от ОРМ. То, что вы делаете, представляет собой дополнительный слой косвенности, именно для того, чтобы оставить вашу модель домена (которая также включает в себя интерфейсы репозитория), не затронутой конкретным материалом уровня сохранения.

Если вы по-прежнему абсолютно уверены, что Generic Repository является лучшим компромиссом для вас с точкой зрения усиления за счет повторного использования коды (который я рекомендовал бы первое дело сложного), Грег Янг gives us разумной середины:

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

Вы можете использовать тот же подход и воспользоваться этим швом, чтобы отобразить модель модели модели/модели устойчивости в миксе.

Что-то вдоль этих линий может быть (не проверено):

public class FooRepository 
{ 
    private PersistenceRepository<FooPersistence> _innerRepository; 

    public Foo GetFooById(int id) 
    { 
     return MapToDomain(_innerRepository.GetById(id)); 
    } 

    public void Add(Foo foo) 
    { 
     _innerRepository.Add(MapToPersistence(foo)); 
    } 

    public IEnumerable<Foo> GetByCity(string city) 
    { 
     return _innerRepository.Find(f => f.City == city).Select(MapToDomain); 
    } 

    private Foo MapToDomain(FooPersistence persistenceModel) 
    { 
     // Mapping stuff here 
    } 

    private FooPersistence MapToPersistence(Foo foo) 
    { 
     // Mapping stuff here 
    } 
} 

public class PersistenceRepository<T> where T : PersistenceModel 
{ 
    public T GetById(int id) 
    { 
     //... 
    } 

    public void Add(T t) 
    { 
     //... 
    } 

    public IQueryable<T> Find(Func<T, bool> predicate) 
    { 
     //... 
    } 
} 

public abstract class PersistenceModel 
{ 
} 

public class FooPersistence : PersistenceModel 
{ 
    public string City { get; set; } 
} 
+0

Спасибо за большое решение – roro2012

+0

У меня есть еще одна проблема.Как использовать шаблон спецификации по-новому – roro2012

+0

примечание. Спецификации - поведение модели домена и не постоянство. – roro2012