Wie eine anbieterunabhängige DAL entwerfen

Question

ich zur Zeit eine Query Builder-Anwendung entwickle, im Grunde eine einfache grafische Oberfläche, den Anwender ohne SQL-Kenntnisse ermöglichen sollte verschiedene Abfragen in einer Datenbank zu definieren (Joins SELECT, INSERT, UPDATE, DELETE). Ich werde .NET 3.5 verwenden. Meine Anwendung mehr Datenbanken unterstützen sollte, sollte es mit MS-SQL-Server, MySQL und Oracle arbeiten, so würde ich irgendwelche Hinweise oder Links zu relevantem Vortrag über schätzen, wie eine anbieterunabhängige DAL zu entwerfen .

Der Benutzer wird einen Datenbankserver, eine Datenbank auf dem aktuellen Server auswählen, um die Verbindungsanmeldeinformationen bereitstellen, verschiedene Tabellen wählen, Abfragen definieren (eine Reihe von Kombinationsfeldern verwenden) und schließlich die Abfragen ausführen, wenn sie gültig sind. Natürlich in der DAL will ich Methoden für jeden DB-Provider haben. Ich denke, etwas auf den Linien der Fabrik-Muster.

. Hinweis: Dies ist ein einfaches Schulprojekt, so dass ich interessiere mich nicht für die Sicherheit oder die Leistung der resultierenden Abfragen

UPDATE: Nach einiger mehr Forschung und mit dem sehr wertvollen Beitrag, die Sie zur Verfügung gestellt haben, entschied ich mich DbProviderFactory zu verwenden. ORM wäre interessant, aber da ich nur einen Query Analyzer / builder will, sehe ich nicht den Punkt, ein zu verwenden. Also, ich würde schätzen, wenn Sie mich zu einer ausführlichen Anleitung, wie man DbProviderFactory und die damit verbundenen Klassen verwenden verweisen würde.

Answer 1

Ich empfehle die System.Data.Common.DbProviderFactories-Klasse generic ADO.NET-Klassen zu erzeugen.

Wenn Sie mehr .NET-Provider für Datenbanken, die Sie unterstützen möchten finden, setzen Sie einfach den Provider-DLL im Pfad des App und einen Verweis auf die DbProviderFactory des Anbieters in der app.config Datei hinzufügen. Sie können die Benutzer die Anbieter auswählen zu können.

Hier ist ein MSDN-Artikel zum Thema namens Beziehen eines DbProviderFactory (ADO. NET)

Ich habe diesen Ansatz vor und in der Lage gewesen, MSSQL und SQLite im selben Projekt mit einer kleinen Konfigurationsänderung zu unterstützen.

Nicht sicher, ob es auch für eine Query Builder App arbeiten werde, obwohl ...

Answer 2

Ich muss sagen, dass eine einigermaßen komplexe Abfrage Bearbeitung visuell ist sehr umständlich. Und damit die Benutzer zum Einfügen / Löschen von Daten visuelle Designer verwenden, ist eine bestimmte Art und Weise selbst in dem Fuß zu schießen. Eine Größe-down-Version von Management Studio, Kenntnisse der grundlegenden SQL Plus beschränkt Server Benutzer wird eine viel bessere Arbeit tun.

Wenn Sie immer noch geneigt sind diese App zu entwerfen, werden Sie NHibernate benötigen. Genauer gesagt, Kriterien Abfragen den Job tun, da sie ziemlich Karte in der Nähe zu dem, was Sie benötigen.

Answer 3

Sie könnten überrascht sein, aber eine sehr einfache providerunabhängige DAL kann mit einfachen alten erreicht werden DataSet und DataTable .

Answer 4

Ich denke, ADO.NET Entity Framework (verfügbar seit .NET 3.5 SP1) eine gute Wahl, da es ziemlich abstrahiert Datenbank abhängige SQL mit seiner Einheit SQL-Sprache ist.

Answer 5

Die meisten jede ORM (Object-Relational-Mapper) wird wissen, wie eine Vielzahl von Datenbanktypen zu sprechen.

Wie für die Benutzer ihre eigenen Abfragen zu erstellen: Sie sehr vorsichtig mit diesem sein müssen. Es ist nicht so sehr, dass Benutzer bösartige Abfragen erstellen könnten (obwohl das ein Problem sein kann), wie es Zufall ist. Es ist überraschend einfach, eine Abfrage zu schreiben, die alle verfügbaren Server-Ressourcen nutzen und eine effektives Denial-of-Service für Ihre Datenbank erstellen.

Answer 6

Ich bin mir nicht sicher, ob dies mit Ihrem Streben unterstützt, aber eine Sache habe ich gelernt, eher vor kurzem und nahm zu Herzen Datenmodelles der eindeutige Kennung Implementierung nicht direkt außerhalb der Datenschicht ausbreiten zu haben sind, aber in einem zu verpackenden Abstraktion. Zum Beispiel, hier ist eine Schnittstelle, die ein Modell Kennung Wraps:

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

Ihre Business-Logik-Schicht, die in der Vergangenheit um ints als eindeutige Kennungen übergeben hat (zum Beispiel von einer Identitätsspalte in der Datenbank-Tabelle), wird nun als solche übergeben:

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

Ihre Datenschicht wird dann eine Klasse, die IModelIdentifier<Person> implementiert und füllt seinen internen Datentyp mit dem eindeutigen Kennung des physischen Modells. Dies dämmt Ihre Business-Schicht von irgendwelchen Änderungen an der Datenschicht kann, wie Ihre int Schlüsselkennungen mit Guids ersetzt werden.