Как создать независимый провайдер 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 по теме: Obtaining a DbProviderFactory (ADO.NET)

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

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

Answer 2

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

Answer 3

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

простой старый DataSet и DataTable.

Answer 4

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

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

Answer 5

Большинство ORM (Object-Relational Mapper) будут знать, как разговаривать с различными типами баз данных.

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

Answer 6

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

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 сек в качестве уникальных идентификаторов (например, из столбца идентификаторов в таблице базы данных), теперь передаются как таковые:

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

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