Comment concevoir un DAL fournisseur indépendant

Question

Je développe actuellement une application de générateur de requêtes, essentiellement, une interface graphique simple qui devrait permettre aux utilisateurs sans connaissance de SQL pour définir différentes requêtes sur une base de données (jointures, SELECT, INSERT, UPDATE, DELETE). Je vais utiliser .NET 3.5. Mon application doit prendre en charge plusieurs bases de données, il devrait fonctionner avec MS-SQL Server, MySQL et Oracle, donc j'apprécierait des conseils ou des liens vers conférences pertinentes sur comment concevoir un DAL fournisseur indépendant .

L'utilisateur sélectionne un serveur de base de données, une base de données sur le serveur en cours, fournir les informations d'identification de connexion, choisissez différentes tables, définir des requêtes (à l'aide d'une série de boîtes combo) et enfin exécuter les requêtes si elles sont valides. Bien sûr, dans le DAL je ne veux avoir des méthodes pour chaque fournisseur DB. Je pense quelque chose sur les lignes du modèle d'usine.

Note:. C'est un simple projet d'école, donc je ne suis pas intéressé par la sécurité ou les performances des requêtes résultant

Mise à jour: Après quelques recherches et avec l'entrée très précieux que vous avez fourni, j'ai décidé d'utiliser DbProviderFactory. ORM serait intéressant, mais comme je veux juste un analyseur de requête / constructeur, je ne vois pas le point d'utiliser un. Donc, je vous serais reconnaissant si vous me pointer vers un tutoriel détaillé sur la façon d'utiliser DbProviderFactory et les classes associées.

Answer 1

Je recommande d'utiliser la classe System.Data.Common.DbProviderFactories pour générer des classes ADO.NET génériques.

Comme vous le trouverez plus des fournisseurs de bases de données .NET pour que vous souhaitez soutenir, il suffit de déposer la DLL du fournisseur dans le chemin de l'application et ajouter une référence à la DbProviderFactory du fournisseur dans le fichier app.config. Vous pouvez avoir l'utilisateur de sélectionner le fournisseur à utiliser.

Voici un article MSDN sur le sujet appelé Obtenir un DbProviderFactory (ADO. NET)

Je l'ai utilisé cette approche avant et été en mesure de soutenir MSSQL et SQLite dans le même projet avec un changement de configuration mineure.

Je ne sais pas si ça va marcher aussi bien pour une application de générateur de requêtes si ...

Answer 2

Je dois dire que la modification d'une requête assez complexe est visuellement très encombrant. Et en permettant aux utilisateurs d'insérer / supprimer des données en utilisant le concepteur visuel est une certaine façon de vous tirer dans le pied. Une version de taille vers le bas de Management Studio, la connaissance de SQL de base et l'utilisateur du serveur restreint fera un bien meilleur travail.

Si vous êtes toujours enclin à concevoir cette application, vous aurez besoin NHibernate. Plus précisément, Requêtes Critères fera le travail, car ils jolie carte à ce que vous avez besoin.

Answer 3

Vous pourriez être surpris, mais un DAL fournisseur indépendant très simple peut être réalisé avec bon vieux DataSet et DataTable .

Answer 4

Je pense que ADO.NET Entity Framework (disponible depuis .NET 3.5 SP1) est un excellent choix car il à peu près fait abstraction SQL en fonction de la base de données avec son entité langage SQL.

Answer 5

La plupart tout ORM (Object-Relational Mapper) saura parler à une variété de types de bases de données.

pour permettre aux utilisateurs de construire leurs propres requêtes: vous devez être très prudent. Ce n'est pas tellement que les utilisateurs puissent créer des requêtes malveillantes (si cela peut être un problème) car il est un accident. Il est étonnamment facile d'écrire une requête qui utilisera toutes les ressources serveur disponibles et créer un déni efficace de service pour la base de données.

Answer 6

Je ne sais pas si cela aide à votre quête, mais une chose que j'ai appris assez récemment et pris à cœur est d'avoir unique, la mise en œuvre de l'identifiant de votre modèle de données ne se propagent directement à l'extérieur de la couche de données, mais être enveloppé dans un abstraction. Par exemple, voici une interface qui enveloppe l'identifiant d'un modèle:

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

Votre couche logique métier, qui peut avoir dans le passé passé autour ints comme des identificateurs uniques (par exemple, à partir d'une colonne d'identité dans votre base de données), est maintenant passé en tant que tel:

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

Votre couche de données aura alors une classe qui implémente IModelIdentifier<Person> et renseigne son type de données interne avec l'identifiant unique du modèle physique. Cette couche de votre isole entreprise de tout changement que vous pourriez avoir à la couche de données, telles que le remplacement de votre int identificateurs clés avec Guids.