Cómo diseñar un DAL independiente del proveedor

Question

Actualmente estoy desarrollando una aplicación de generador de consultas, básicamente, una interfaz gráfica simple que debe permitir a los usuarios sin conocimientos de SQL para definir varias consultas en una base de datos (se une, SELECT, INSERT, UPDATE, DELETE). Me va a utilizar .NET 3.5. Mi aplicación debe soportar múltiples bases de datos, que debería funcionar con MS-SQL Server, MySQL y Oracle, por lo que agradecería cualquier insinuación o enlaces a conferencia pertinente sobre cómo diseñar un DAL independiente del proveedor .

El usuario seleccionará un servidor de base de datos, una base de datos en el servidor actual, proporcionar las credenciales de conexión, seleccionar varias tablas, definir consultas (utilizando una serie de cuadros combinados) y, finalmente, ejecutar las consultas si son válidos. Por supuesto, en el DAL yo quiero tener métodos para cada proveedor de base de datos. Estoy pensando algo en las líneas del patrón de la fábrica.

Nota:. Se trata de un proyecto escolar sencillo, así que no estoy interesado en la seguridad o el rendimiento de las consultas resultantes

ACTUALIZACIÓN: Después de un poco más de investigación y con la entrada muy valiosa que nos ha proporcionado, decidí usar DbProviderFactory. ORM sería interesante, pero como yo sólo quiero un analizador de consultas / constructor, no veo el punto de utilizar una. Por lo tanto, le agradecería si me apunte a un tutorial detallado sobre cómo utilizar DbProviderFactory y las clases asociadas.

Answer 1

recomiendo el uso de la clase System.Data.Common.DbProviderFactories para generar clases de ADO.NET genéricas.

A medida que encuentre más proveedores de .NET para bases de datos que desea apoyar, sólo tiene que colocar el archivo DLL de proveedor en el camino de la aplicación y añadir una referencia a la DbProviderFactory del proveedor en el archivo app.config. Puede hacer que el usuario seleccione el proveedor de usar.

Aquí está un artículo de MSDN en el tema denominado La obtención de un DbProviderFactory (ADO. NET)

He utilizado este método antes y ha sido capaz de soportar MSSQL y SQLite en el mismo proyecto con un cambio en la configuración de menor importancia.

No está seguro, si funcionará tan bien para una aplicación de generador de consultas, aunque ...

Answer 2

debo decir que editar una consulta razonablemente complejo visualmente es muy engorroso. Y permitiendo a los usuarios insertar / borrar datos utilizando el diseñador visual es de cierta manera para disparar en el pie. Una versión de tamaño abajo de Gestión de estudio, conocimientos de SQL básico más restringido de usuario del servidor va a hacer un trabajo mucho mejor.

Si usted todavía está inclinado a diseñar esta aplicación, tendrá que NHibernate. Más precisamente, consultas Criterios hará el trabajo, ya que bastante mapa cerca de lo que necesita.

Answer 3

Puede que se sorprenda, pero una muy sencilla DAL independiente del proveedor que puede lograrse con el viejo y simple DataSet y DataTable .

Answer 4

Creo ADO.NET Entity Framework (disponible desde .NET 3.5 SP1) es una gran opción ya que más o menos de distancia resúmenes de base de datos SQL-dependiente con su lenguaje SQL entidad.

Answer 5

La mayoría de cualquier ORM (Object-Relational Mapper) sabrá cómo hablar con una variedad de tipos de bases de datos.

En cuanto a lo que permite a los usuarios crear sus propias consultas: hay que tener mucho cuidado con esto. No es tanto que los usuarios pueden crear consultas maliciosos (aunque eso puede ser un problema), ya que es accidente. Es sorprendentemente fácil de escribir una consulta que va a utilizar todos los recursos disponibles del servidor y crear una negación efectiva del servicio para su base de datos.

Answer 6

No estoy seguro de si esto ayuda con su búsqueda, pero una cosa que aprendí hace relativamente poco y tomé a pecho es tener aplicación identificador único de su modelo de datos se propaga directamente fuera de la capa de datos, sino para ser envuelto en una abstracción. Por ejemplo, aquí es una interfaz que se envuelve identificador de un modelo:

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);
}

Su capa de lógica de negocio, que puede tener en el pasado pasado alrededor ints como identificadores únicos (por ejemplo, a partir de una columna de identidad en la tabla de base de datos), ahora se pasa como por ejemplo:

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

Su capa de datos tendrá entonces una clase que implementa IModelIdentifier<Person> y rellena su tipo de datos interna con el identificador único del modelo físico. Esto aísla su capa de negocio de cualquier cambio que pueda tener en la capa de datos, tales como la sustitución de su int identificadores de clave con Guids.