Структура хранилища Путаница

Question

public class CarRepository:IC 
{ 
    public IRD ReferenceDataRepositry{get;set;} 
    public string SaveCar(Car car) 
    { 
     //get data from reference data repository 
    } 
} 

public class ReferenceDataRepository:IRD 
{ 
    public string Get(string id) 
    { 

    } 

} 

При сохранении данных в репозитории я хочу получить данные из репозитория референтных данных, чтобы установить некоторые из свойств.

Вопрос: Должен ли один репозиторий узнать о другом репозитории? Я использую инъекцию зависимостей для установки репозитория ссылочных данных, должен ли я устанавливать репозитории внутри репозиториев?

Answer 1

Вы можете, там DI просто заявляет, что объект зависит от другого, но не несет ответственности за создание экземпляра зависимости.

Однако я бы ввел чтение REPO в репо-запись. это просто чтение и запись. получить объект и сохранить объект. все еще остается ответственность за фактическое изменение объекта. это произойдет в другом компоненте. как действие контроллера или фасад службы.

Answer 2

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

Шаблон репозитория предназначен для развязки уровня доступа к данным с бизнес-уровня и путем объединения разных хранилищ, позволяющих вашей бизнес-логике сливаться с уровнем данных, что противоречит первоначальной цели использования этого шаблона проектирования.

КПП. Хорошей практикой является отделить метод, который меняет данные из тех, которые их читают.

Answer 3

Репозиторий шаблон, как описано by Microsoft о инкапсуляции логики и как отделить логику, которая извлекает данные и отображает его в модели объекта из бизнес-логики, которая действует на модели.

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

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

Answer 4

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

public interface DomainRepository 
{ 
Entity Get(int id); 
bool VerifySomeAspect(); 
Save(Entity data); 
} 

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

Событие, если какой-то метод будет дублироваться, тогда я делаю его внутренним и статическим, передавая все необходимые ему аргументы, но я бы не вводил другое репо. Вероятно, в 95% случаев вам не нужно это делать, если каждый репозиторий несет ясную ответственность и обслуживает только один контекст.

Это также означает, что вы не идете с общим репозиторием. Разместите каждое репо в соответствии с потребностями слоев/контекстов и не впадайте в ловушку «я должен действительно использовать столько, сколько смогу». Повторное использование является хорошим, но сложным в этой ситуации.