Различные реализации репозитория базы данных за одним интерфейсом

Question

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

Прежде всего, я хотел бы поддержать два типа связи с базой данных - прямые запросы sql (например, вставить, обновить и т. Д.) И объемные вставки, такие как загрузка данных из файла (или другого источника). Тем не менее, оба эти осуществлений делать разные вещи:

• Простого хранилище выстреливает запрос к SQL серверу
• Объемное хранилище первым добавляет запись в файл или в памяти. После обработки всех записей он синхронизируется с базой данных.

Моя первая попытка классовой структуры для этого:

public class Product{ 

    } 

    public interface IProductRepository { 
    Product GetProduct(int id); 
    void CreateProduct(Product p); 
    } 

    public class SqlProductRepository : IProductRepository 
    { 
    public Product GetProduct(int id) 
    { 
     throw new NotImplementedException(); 
    } 

    public void CreateProduct(Product p) 
    { 
     throw new NotImplementedException(); 
    } 
    } 

    public class BulkLoadRepository : IProductRepository 
    { 
    public Product GetProduct(int id) 
    { 
     throw new NotImplementedException(); 
    } 

    public void CreateProduct(Product p) 
    { 
     throw new NotImplementedException(); 
    }  
    } 

Тем не менее, эта структура отсутствует функцию синхронизации в конце для объемного хранилища. Если я добавлю функцию Sync(), мне нужно будет оставить ее пустой для «простого» репозитория.

Любые мысли о том, как поддерживать обе функции, но все же скрывать их за одним интерфейсом?

Заранее благодарен!

Answer 1

Прежде всего, почему вы создаете интерфейс для каждого типа объекта. Обычно в репозитории просто есть методы Get, Create, Update, Delete, возможно, общий Get ... где IRepository также является общим.

У вас может быть второй интерфейс, наследующий IRepository, который имеет метод Sync, и только массивный репозиторий реализует его. В этом случае вы все равно можете получить доступ к обеим репозиториям methods defined by IProductRepository`

Или иметь базовый класс для массовых хранилищ, который реализует/определяет синхронизацию.

Answer 2

Я не уверен, почему вы оставите его пустым для простого хранилища. Sync == Commit в большинстве моих репозиториев. Хотя более точно это шаблон UnitOfWork, а не шаблон репозитория.

Воздействие отдельного метода фиксации очень распространено для транзакционных систем.

Repository and Unit of Work patterns - How to save changes