В настоящее время мы реализовали шаблон репозитория на работе. Все наши репозитории располагаются за собственными интерфейсами и отображаются через Ninject. Наш проект довольно большой, и есть несколько причуд с этой моделью, которую я пытаюсь решить.
Во-первых, есть некоторые контроллеры, в которых нам требуется более 10-15 репозиториев, все в одном контроллере. Конструктор становится довольно уродливым, когда спрашивает столько репозиториев. Вторая причуда проявляется после вызова методов в нескольких репозиториях. После выполнения работы с несколькими репозиториями нам нужно вызвать метод SaveChanges, но в каком репозитории мы его будем называть? В каждом хранилище есть один. Все репозитории имеют один и тот же экземпляр контекста данных Entity Framework, который был введен, поэтому выбор любого случайного хранилища для вызова save on будет работать. Это просто кажется грязным.
Я посмотрел шаблон "Unit Of Work" и придумал решение, которое, как я думаю, решает обе проблемы, но я не уверен на 100% в этом решении, поэтому любые отзывы приветствуются. Я создал класс под названием DataBucket (в основном потому, что мне не нравится называть его UnitOfWork. Это звучит забавно.).
// Slimmed down for readability
public class DataBucket
{
private DataContext _dataContext;
public IReportsRepository ReportRepository { get; set; }
public IEmployeeRepository EmployeeRepository { get; set; }
public IDashboardRepository DashboardRepository { get; set; }
public DataBucket(DataContext dataContext,
IReportsRepository reportsRepository,
IEmployeeRepository employeeRepository,
IDashboardRepository dashboardRepository)
{
_dataContext = dataContext;
this.ReportRepository = reportsRepository;
this.EmployeeRepository = employeeRepository;
this.DashboardRepository = dashboardRepository;
}
public void SaveChanges()
{
_dataContext.SaveChanges();
}
}
Это, похоже, решает обе проблемы. Теперь в ведро данных есть только один метод SaveChanges, и вы вводите только один объект - ведро данных. Затем вы получаете доступ ко всем хранилищам как свойствам. Ведро данных было бы немного грязным, поскольку оно принимало бы ВСЕ (легко 50 или более) наших репозиториев в его конструкторе.
Процесс добавления нового репозитория теперь включает в себя: создание интерфейса, создание репозитория, отображение интерфейса и репозитория в Ninject и добавление свойства в ведро данных и его заполнение.
Я подумал об альтернативе этому, чтобы устранить шаг сверху.
public class DataBucket
{
private DataContext _dataContext;
public IReportsRepository ReportRepository { get; set; }
public IEmployeeRepository EmployeeRepository { get; set; }
public IDashboardRepository DashboardRepository { get; set; }
public DataBucket(DataContext dataContext)
{
_dataContext = dataContext;
this.ReportRepository = new ReportsRepository(dataContext);
this.EmployeeRepository = new EmployeeRepository(dataContext);
this.DashboardRepository = new DashboardRepository(dataContext);
}
public void SaveChanges()
{
_dataContext.SaveChanges();
}
}
Это довольно сильно устраняет все сопоставления репозитория в Ninject, потому что все они созданы в веществе данных. Итак, теперь шаги по добавлению нового репозитория включают: создание интерфейса, создание репозитория, добавление свойства в ведро данных и создание экземпляра.
Можете ли вы, ребята, увидеть недостатки этой модели? На первый взгляд гораздо удобнее использовать наши хранилища таким образом. Это проблема, которая была рассмотрена раньше? Если да, то каков наиболее общий и/или наиболее эффективный подход к этой проблеме?
Спасибо:)
