перевести это в шаблон общего репозитория

Question

Я начал переводить проект в общий репозиторий и единицу рабочего шаблона. До сих пор мне удалось перепроектировать все прямые ссылки на контексты в контроллерах в общий репозиторий; Однако, у меня возникли проблемы со следующими двумя строками кодов:

`context.Entry(ticket).Collection(i => i.TicketItems).Load(); 
      ticket.TicketItems.Clear();` 

Это то, что мой контроллер делал перед тем, чтобы исключить любые ссылки между Ticket и TicketItem. Между Ticket и TicketItem существует отношение «многие ко многим». Таким образом, эти две строки кода, что я использовал до того, чтобы удалить все TicketItems из Ticket

Answer 1

Вы можете иметь два метода в интерфейсе хранилища - один для навигационных ссылок и один для навигации коллекции:

public interface IRepository<T> 
{ 
    void LoadNavigationReference<TReference>(T entity, 
     Expression<Func<T, TReference>> navigationProperty, 
     params Expression<Func<TReference, object>>[] includes) 
     where TReference : class; 

    void LoadNavigationCollection<TElement>(T entity, 
     Expression<Func<T, ICollection<TElement>>> navigationProperty, 
     params Expression<Func<TElement, object>>[] includes) 
     where TElement : class; 
} 

Предполагается, что они должны поддерживать другие вложенные навигационные свойства. Реализация будет:

public class Repository<T> : IRepository<T> 
    where T : class 
{ 
    private readonly MyContext _dbContext; 

    public Repository(MyContext dbContext) 
    { 
     _dbContext = dbContext; 
    } 

    public void LoadNavigationReference<TReference>(T entity, 
     Expression<Func<T, TReference>> navigationProperty, 
     params Expression<Func<TReference, object>>[] includes) 
     where TReference : class 
    { 
     if (includes == null || includes.Length == 0) 
      _dbContext.Entry(entity).Reference(navigationProperty).Load(); 
     else 
      _dbContext.Entry(entity).Reference(navigationProperty).Query() 
       .IncludeMultiple(includes).Load(); 
    } 

    public void LoadNavigationCollection<TElement>(T entity, 
     Expression<Func<T, ICollection<TElement>>> navigationProperty, 
     params Expression<Func<TElement, object>>[] includes) 
     where TElement : class 
    { 
     if (includes == null || includes.Length == 0) 
      _dbContext.Entry(entity).Collection(navigationProperty).Load(); 
     else 
      _dbContext.Entry(entity).Collection(navigationProperty).Query() 
       .IncludeMultiple(includes).Load(); 
    } 
} 

метод IncludeMultiple расширения, используемый выше берется из Ladislav Mrnka's answer here.

Пример ваш вопрос будет выглядеть следующим образом:

repository.LoadNavigationCollection(ticket, i => i.TicketItems); 
ticket.TicketItems.Clear(); 

где repository имеет тип IRepository<Ticket>.

Если TicketItem было другое свойство навигации, скажет TicketItemDetails, вы могли бы охотно загрузить его вместе с TicketItems таким образом:

repository.LoadNavigationCollection(ticket, i => i.TicketItems, 
    t => t.TicketItemDetails); 

Редактировать

BTW как критическое примечание стороны о родовых Хранилище: выше является частью общего репозитория, который имеет на самом деле 16 методов и что я использовал на ранней стадии проекта, прежде чем я остановился, чтобы его расширить и полностью отказался от этого стиля.

В начале хранилища было около 5 методов (как и большинство обычных репозиториев, которые вы видите в Интернете). Было невозможно работать только с этими 5 способами, не теряя при этом много возможностей Entity Framework. Поэтому мне нужно было продлить его шаг за шагом, руководствуясь реальными потребностями в проекте, и он никогда не становился «полным», прежде чем я удалил его из проекта.

Проблема заключается в следующем: если вы продемонстрируете интерфейс кому-либо («здесь у меня есть супер общий и независимый от технологии интерфейс доступа к данным»), он сразу сказал бы «ага, вы используете Entity Framework!». Причина в том, что почти каждый метод является всего лишь оберткой вокруг метода Entity Framework, и вы не можете скрыть это, используя другие имена для методов интерфейса. Весь интерфейс пахнет EF DbContext/Code-First.

Теперь попробуйте реализовать этот интерфейс с другой технологией, чем Entity Framework. Скорее всего, вы столкнетесь с той же проблемой, что и я: Множество методов отсутствует, чтобы использовать возможности этой другой технологии или существующие методы имеют неправильные параметры или существует слишком много методов, которые вы не можете разумно реализовать с помощью другого технологии.

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

На мой взгляд, такой общий репозиторий является типичным примером Leaky Abstraction, где реальная реализация, которую вы имеете в виду, светит через весь интерфейс.

Но если вы не можете абстрагировать использование Entity Framework, создание универсального интерфейса репозитория довольно бессмысленно.