LINQ-XYZ полиморфизм?

Question

У меня есть ситуация, когда клиент требует, чтобы мы внедрили наш код доступа к данным для использования базы данных Oracle или SQL-сервера на основе параметров конфигурации среды выполнения. Производственная среда использует Oracle, но и dev, и QA работают с экземпляром SQL Server.

(Я не имею никакого контроля над этим или не знаю, почему это так, за исключением того, что Oracle является их платформой BI и dev хочет работать с SQL Server.)

Их запрос состоит в том, чтобы использовать LINQ-to-SQL / LINQ-to-Oracle для любого доступа к данным. Им нужно будет поддержать приложение и пока не иметь знаний, чтобы перейти на EF (их требование) - хотя я полагаю, что такая же проблема существует, если мы используем EF.

Хотя я могу реализовать классы LINQ to XYZ для обеих баз данных, чтобы я мог подключиться к обеим, они не имеют общего интерфейса (кроме DataContext), поэтому я действительно не могу кодировать интерфейс и подключить фактическую реализацию во время выполнения.

Есть идеи, как мне к этому подойти?

UPDATE После написания этой статьи я провел небольшое исследование EF, и мне кажется, что такая же проблема существует, если я использую EF - что будет моей долгосрочной целью.

Answer 1

Что вам нужно сделать, так это инкапсулировать текст данных ORM в интерфейс вашего создания, такой как IDataContext.

Затем поделитесь этим интерфейсом между всеми DAL и внедрите его. То, как вы его подключите, это только ваши предпочтения, используя MEF, как предложено, или контейнер IoC.

Answer 2

Ради замысла этой темы вот что я в итоге сделал:

Я реализовал комбинацию шаблонов «Единица работы» и «Репозиторий». Класс Unit of Work - это то, с чем работает потребляющий код, и он предоставляет все операции, которые могут быть выполнены с моими корневыми объектами. Существует одно UoW на корневую сущность. UoW использует класс репозитория через интерфейс. Фактическая реализация хранилища зависит от используемой технологии доступа к данным.

Так, например, если у меня есть сущность клиента, и мне нужно поддерживать извлечение и обновление каждой записи, у меня будет что-то вроде:

public interface ICustomerManager
{
    ICustomer GetCustomer(Guid customerId);
    void SaveCustomer(ICustomer customer);
}

public class CustomerManager : ICustomerManager
{
    public CustomerManager(ICustomerRepository repository)
    {
        Repository = repository;
    }

    public ICustomerRepository Repository { get; private set; }

    public ICustomer GetCustomer(Guid customerId)
    {
        return Repository.SingleOrDefault(c => c.ID == customerId);
    }

    public void SaveCustomer(ICustomer customer)
    {
        Repository.Save(customer);
    }
}

public interface ICustomerRepository : IQueryable<ICustomer>
{
    void Save(ICustomer customer);
}

Я использую платформу Inversion of Control для внедрения реализации ICustomerRepository в класс CustomerManager во время выполнения. Класс реализации будет находиться в отдельной сборке, которую можно заменить при изменении технологии доступа к данным. Все, что нас беспокоит, - это то, что хранилище реализует каждый метод, используя контракт, определенный выше.

В качестве примечания, чтобы сделать это с Linq-to-SQL, я просто создал класс LinqCustomerRepository, который реализует ICustomerRepository, и добавил частичный класс для сгенерированного класса сущностей Customer, который реализует ICustomer. Затем я могу вернуть сущность L2S из репозитория в качестве реализации интерфейса ICustomer для работы с UoW и вызывающим кодом, и они не будут мудрее, если сущность возникла из кода L2S.

Answer 3

Просто быстрая мысль.Используйте MEF framework и подключите к нему слои DAL.Затем в зависимости от среды (dev, production, QA) вы можете переключаться на различные уровни DAL (Oracle, SQL и т. Д.).

Если вы хотите узнать о MEF, здесь - этократкое введение.

Также некоторое время назад я видел Универсальную платформу доступа к данным Джойдипа Канджилала.Вы даже можете взглянуть на это.