Как использовать два хранилища данных для одного и того же интерфейса в шаблоне репозитория?

Question

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

Что я НЕ получаю, так это то, как поддерживать несколько хранилищ данных одновременно. Вот пример, предположим, что я определил репозиторий IPersonRepository, который имеет две реализации, и требование - читать XML-файл и хранить его в базе данных SQL или наоборот.

DataAccessLayer

public interface IPersonRepository 
{ 
    Person GetPersonById(int id); 
} 

public class PersonRepositorySQL : IPersonRepository 
{ 
    public Person GetPersonById(int id) 
    { 
     // get person from sql db (using ado.net) 
    } 
} 

public class PersonRepositoryXML : IPersonRepository 
{ 
    public Person GetPersonById(int id) 
    { 
     // get person from xml file 
    } 
} 

BusinessLogicLayer

public PersonService 
{ 
    private IPersonRepository personRepository; 

    public PersonService(IPersonRepository personRepository) 
    { 
     this.personRepository = personRepository; 
    } 

    public Person GetPersonById(int id) 
    { 
     personRepository.GetPersonById(id); 
    } 
} 

Вопросы (упорядоченные по важности):

1. это означает, что я должен создать экземпляр два PersonService объекты ли каждый раз для чтения данных из db и xml путем передачи PersonRepositorySQL и PersonRepositoryXML соответственно?
2. Чтобы сделать выше, я должен добавить ссылку на репозитории на верхнем уровне (в основном презентация)? Как этого можно избежать?
3. Является ли DAL хорошим местом для хранения репозиториев?
4. Можно ли назвать класс BLL службой ex: PersonService?

Я понимаю, что сообщение стало очень длинным, но я хотел поставить все, что вызывает путаницу.

- Н.В.

Answer 1

Означает ли это, что я должен создать экземпляр два PersonService объекты каждый раз для чтения данных из БД и XML, передавая PersonRepositorySQL и PersonRepositoryXML соответственно?

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

Ответственность за подключение двух хранилищ, а не клиента, лежит на обслуживании.

Затем используйте контейнер IoC для установки и предоставления экземпляра службы клиентам, наличие новых сервисов() по всему месту определенно не рекомендуется. Вам нужно будет найти инструменты/подход IoC, которые лучше всего подходят для любой технологии презентации, которую вы используете.

Для выполнения вышеизложенного, я должен добавить ссылку на репозитории на верхнем уровне (в основном презентация)? Как этого можно избежать?

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

Я нашел, что Googling для структуры структуры многослойной архитектуры VS (или аналогичной) помог мне сброситься назад, когда я не был уверен.

Является ли DAL хорошим местом для хранения репозиториев?

Вот где они должны быть. Ваш DAL обычно используется для всего, что касается аппаратных, то есть файлов, dbs, webapis.

Можно ли назвать класс BLL Службой ex: PersonService?

Абсолютно. Это коротко, приятно и говорит людям (и другим разработчикам), что это (услуга) и каковы его обязанности (люди)

Answer 2

Просто для ответа на вопрос № 1: вместо создания двух служб вы можете создать экземпляр одной службы и передать в него Composite. Для этого вам понадобится тип CompositeRepositoryFactory, который создаст соответствующий Composite. Обратите внимание, что

Немного больше о Composite и вашего конкретного случая:

• Это позволяет нескольким реализациям цепи в то время как клиент хранит ссылку на оригинальный интерфейс.
• Позволяет цепочки нескольких реализаций одного и того же интерфейса. Таким образом, реализации каскадируют вызовы метода, что позволяет использовать более богатую логику. С другой стороны, клиент поддерживает требуемую зависимость: только на самом интерфейсе.
• Композитный шаблон облегчает принцип SRP: если ваш класс слишком обширен и имеет большой интерфейс, вы не сможете его украсить, потому что: Трудно точно реализовать украшение (так как класс делает слишком много) ,
• На рисунке ниже: клиент имеет ссылку на CompositeComponent (через контрольную переменную IComponent). CompositeComponent ссылается на другую реализацию IComponent (например, ConcreteComponent), собственную логику в пределах Something(), а затем как часть этой логики - она ​​вызывает ConcreteComponent.Something(). Таким образом, начальный вызов CompositeComponent.Something() каскадов до ConcreteComponent.

• Я также создал быструю схему того, как выше цифра может применить к данному случаю: Ваш клиентский код будет продолжать использовать PersonService, однако вместо прохождения в некоторых IPersonRepository осуществления непосредственно, вы должны сначала перейти к PersonCompositeRepositoryFactory. Единственное изменение, которое необходимо на разрешение стороны корня будет использование PersonCompositeRepositoryFactory