Как разработать независимый провайдер DAL (.Net)

Question

В настоящее время я разрабатываю приложение для построения запросов, в основном простой графический интерфейс, который должен позволять пользователям, не знакомым с SQL, определять различные запросы к базе данных (объединяет, выбирает, обновляет, вставляет, удаляет). Я буду использовать .Net 3.5. Мое приложение должно поддерживать несколько баз данных, оно должно работать с MS-SQL Server, MySQL и Oracle, поэтому я был бы признателен за любые советы или ссылки на соответствующую лекцию по , как разработать независимый от поставщика DAL .

Пользователь выберет сервер базы данных, базу данных на текущем сервере, предоставит учетные данные подключения, выберет различные таблицы, определит запросы (используя серию комбинированных окон) и, наконец, выполнит запросы, если они действительны. Конечно, в DAL я хочу иметь методы для каждого поставщика БД. Я думаю что-то на линии фабричного образца.

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

ОБНОВЛЕНИЕ: После еще нескольких исследований и с очень ценным вкладом, который вы предоставили, я решил использовать DbProviderFactory. ORM было бы интересно, но так как я просто хочу анализатор / построитель запросов, я не вижу смысла в его использовании. Поэтому я был бы признателен, если бы вы указали мне подробное руководство по использованию DbProviderFactory и связанных с ним классов.

Answer 1

Я рекомендую использовать класс System.Data.Common.DbProviderFactories для генерации общих классов ADO.NET.

Когда вы найдете больше поставщиков .NET для баз данных, которые вы хотите поддерживать, просто перетащите DLL поставщика в путь приложения и добавьте ссылку на DbProviderFactory поставщика в файле app.config. Пользователь может выбрать поставщика для использования.

Вот статья MSDN на эту тему: Получение DbProviderFactory (ADO.NET)

Я использовал этот подход раньше и смог поддерживать MSSQL и SQLite в одном проекте с незначительным изменением конфигурации.

Не уверен, что он будет работать так же хорошо для приложения построителя запросов ...

Answer 2

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

public interface IModelIdentifier<T> where T : class 
{
    /// <summary>
    /// A string representation of the domain the model originated from.
    /// </summary>
    string Origin { get; }

    /// <summary>
    /// The model instance identifier for the model object that this 
    /// <see cref="IModelIdentifier{T}"/> refers to.  Typically, this 
    /// is a database key, file name, or some other unique identifier.
    /// <typeparam name="KeyDataType">The expected data type of the 
    /// identifier.</typeparam>
    /// </summary>
    KeyDataType GetKey<KeyDataType>();

    /// <summary>
    /// Performs an equality check on the two model identifiers and 
    /// returns <c>true</c> if they are equal; otherwise <c>false</c> 
    /// is returned.  All implementations must also override the equal operator.
    /// </summary>
    /// <param name="obj">The identifier to compare against.</param>
    /// <returns><c>true</c> if the identifiers are equal; otherwise 
    /// <c>false</c> is returned.</returns>
    bool Equals(IModelIdentifier<T> obj);
}

Ваш уровень бизнес-логики, который в прошлом мог иметь около int s в качестве уникальных идентификаторов (например, из столбца идентификаторов в таблице базы данных), теперь передается следующим образом:

    public IPerson RetrievePerson(IModelIdentifier<IPerson> personId)
    {
        /// Retrieval logic here...
    }

Тогда ваш уровень данных будет иметь класс, который реализует IModelIdentifier<Person> и заполняет его внутренний тип данных уникальным идентификатором физической модели. Это изолирует ваш бизнес-уровень от любых изменений, которые вы можете иметь на уровне данных, таких как замена ключевых идентификаторов int на Guid s.

Answer 3

Почти любой ORM (Object-Relational Mapper) знает, как общаться с различными типами баз данных.

Что касается разрешения пользователям создавать свои собственные запросы: с этим нужно быть очень осторожным. Это не столько что пользователи могут создавать вредоносные запросы (хотя это может быть проблемой), сколько случайность. На удивление легко написать запрос, который будет использовать все доступные ресурсы сервера и создать эффективный отказ в обслуживании для вашей базы данных.

Answer 4

Я должен сказать, что редактирование достаточно сложного запроса визуально очень громоздко. А разрешение пользователям вставлять / удалять данные с помощью визуального дизайнера - это определенный способ выстрелить себе в ногу. Уменьшенная версия Management Studio, знание базового SQL плюс ограниченный пользователь сервера сделают намного лучшую работу.

Если вы все еще хотите создать это приложение, вам понадобится NHibernate. Точнее, Критерии запросов выполнят эту работу, так как они отображаются достаточно близко к тому, что вам нужно.

Answer 5

Вы можете быть удивлены, но очень простой независимый от поставщика DAL может быть достигнут с помощью:

обычный старый DataSet и DataTable .

Answer 6

Я думаю, что ADO.NET Entity Framework (доступен с версии .NET 3.5 SP1) - отличный выбор, поскольку он в значительной степени абстрагирует SQL, зависящий от базы данных, с помощью языка сущностей SQL.