Design der Datenzugriffsschicht mit mehreren Datenbanken

Question

Ich habe viele Beiträge gelesen, die sich mit der Frage befassen, mehrere Datenbanken zu haben und wie man in diesem Fall eine DAL effizient gestaltet. In vielen Fällen schlägt das Forum vor, das Repository-Muster anzuwenden, was in den meisten Fällen gut funktioniert.

Allerdings finde ich mich in einer anderen Situation. Ich habe 3 verschiedene Datenbanken: Oracle, OLE DB und SQLServer. Gegenwärtig gibt es eine eindeutige DAL mit vielen verschiedenen Klassen, die SQL-Abfragen bis zu einer darunter liegenden Ebene senden, um in der entsprechenden Datenbank ausgeführt zu werden. Die Funktionsweise des Systems besteht darin, dass zwei der Datenbanken nur dazu dienen, Informationen von ihnen zu lesen, während die andere dazu dient, diese Informationen entweder zu speichern oder später zu lesen. Ich muss der aktuellen Implementierung ein besseres Design vorschlagen, aber es scheint, als ob eine gemeinsame Schnittstelle für alle drei Datenbanken aus architektonischer Sicht nicht plausibel ist.

Gibt es ein Entwurfsmuster, das diese Situation löst? Sollte ich drei verschiedene DALs haben? Oder ist es vielleicht (und ratsam), das Repository-Muster auf dieses Problem anzuwenden?

Answer 1

Antworten auf Ihre Frage werden wahrscheinlich sehr subjektiv sein. Dies sind einige Gedanken.

Sie könnten Befehl-Abfrage-Trennung anwenden. Die Abfrageseite integriert sich direkt in Ihre Datenschicht und umgeht alle Geschäfts- oder Domänenebenen. Die zurückkehrenden Entitäten sind für das Lesen und Projekt aus Ihren Datenbanken optimiert. Diese Schicht könnte auch dafür verantwortlich sein, Ergebnisse von verschiedenen Datenbankaufrufen zusammenzuführen.

Die Befehlsseite besteht aus Befehlshandlern, die Domänen- oder Geschäftsentitäten verwenden, die aus Ihrer R/W-Datenbank zugeordnet sind.

Dadurch wird die von Ihnen bereitgestellte Schnittstelle klarer und geschäftsorientierter.

Ich bin mir nicht sicher, ob die Datenzugriffsebene mit benutzerdefinierten Arbeitseinheiten und Repositories vollständig abstrahiert werden muss: Überwiegen die Vorteile die Nachteile? Sie tun es selten, weil Sie jemals eine Datenbank-Technologie ändern werden? Und wenn Sie das tun, bedeutet dies wahrscheinlich eine Neuschreibung. Wenn Sie zuerst Entity Framework-Code verwenden, haben Sie bereits eine Arbeitseinheit und eine Abstraktion oben auf Ihrer Datenbank. und die Flexibilität der Verwendung von LINQ.

Endergebnis - versuchen Sie nicht, über-engineering/über-abstrakte Sachen; oder Dinge super-generisch machen.

Answer 2

Ihr Kern/Geschäftscode sollte niemals von einem Vertrag/einer Schnittstelle/Klasse abhängig sein, der/die in der DAL-Schicht der Anwendung platziert wird.

Der Zugriff auf Daten ist etwas, was die Business/Core-Schicht Ihrer Anwendung tun muss, und dies sollte in der Lage sein, ohne Abhängigkeit von SQL-Anweisungen und ohne Kenntnis der zugrunde liegenden Datenzugriffstechnologie auskommen zu können.

Ich denke, Sie müssen alle "SQL" -Anweisungen aus dem Kern der Anwendung entfernen. SQL ist herstellerabhängig und jede Abhängigkeit von einer bestimmten Datenbank-Engine muss aus Ihrem Kern entfernt und an die DAL verschoben werden, wo sie hingehört. Dann müssen Sie Schnittstellen erstellen, die sich außerhalb der DAL befinden, für die Sie dann Implementierungsklassen für eine oder mehrere DAL-Module/Klassen erstellen. Deine DAL kann von deinem Kern abhängen, aber nicht umgekehrt.

Ich sehe nicht, warum die Repository-Schicht in diesem Fall nicht verwendet werden kann. Wenn ich eine Datenbank habe, von der ich nur lesen kann, lasse ich normalerweise den Namen der Repository-Schnittstelle wie ICompanyRepositoryRead angeben.