Another short piece of personal learning. Ich markiere für einmal den grossen Architekten. :)
Die Idee eines Data Access Layers ist gemeinhin, Datenzugriffe datenbank- oder sogar datenquellenneutral (neben relationalen Datenbanken allein können ja auch Textdateien oder ein Web Service als Datenquelle dienen) zu halten. In der Praxis ist dies nach meinen Erfahrungen nicht immer genau so der Fall, wie dies die Theorie anpreist.
Die Theorie sagt: Der Presentation Layer präsentiert Daten und enthält keine Logik (höchstens formelle Prüfung oder Plausibilisierung von Eingaben), der Business Layer hantiert mit den Business-Objekten und implementiert die Logik, der Data-Access Layer liest und speichert die Daten und abstrahiert die Zugriffe auf die Datenquelle auf allgemeinem Level.
Ich wollte nun einen Business Layer, der weder von der Datenquelle abhängt noch hunderte Zeilen Code enthält, um die netten Rückgabewerte und Ausgabeparameter wieder in Objekte umzubauen. Ich wollte im DAL auch keine Strukturen definieren, dessen Felder denjenigen im Business-Objekt entsprechen. Ein Objekt (Business Entity!) soll "as it is" ohne weitere Bearbeitung zur Speicherung gereicht werden und auch fixfertig wieder aus dem DAL kommen.
Dafür habe ich nun ein separates Assembly gebaut mit abstrakten Basisklassen für die Business-Objekte. Business Layer und DAL haben beide eine Referenz darauf, sodass beide die Grundstruktur der Objekte kennen. Hier eine schnelle PowerPoint-Skizze:
Der Business Layer kann nun dem DAL beliebige Instanzen von Klassen übergeben, welche von den (abstrakten) Basisklassen im DAL abgeleitet sind. Im Business Layer kann ich meine Business-Entitäten erstellen, die von den Basisklassen erben, meine Methoden erstellen und zusätzliche Interfaces implementieren, beispielsweise für bequemes .NET Windows Forms Data Binding.
Zur Implementierung habe ich vorerst nur die gekapselten Felder und das IEquatable Generic Interface in der Basisklasse implementiert: Die Entität soll grundsätzlich sofort einsetzbar sein (für Business-Layer und DAL!), aber keine besonderen Businessfunktionalitäten bereitstellen. Die braucht der DAL nämlich nicht, und hat sie auch nicht zu brauchen.
Nein, allzu neu ist die Idee nicht. Bei simple talk ist die Idee im Artikel ".NET Application Architecture: the Data Access Layer" (der Artikel ist sehr empfehlenswerte Lektüre!) beispielsweise aufgegriffen, diskutiert und Alternativen gegenübergestellt. Sie beschreibt diesen Approach als akademisch:
From an academic standpoint, this approach is probably the truest form of a data abstraction for a DAL because you can make the shared classes completely data-source independent and not just database independent.
Diesen Eindruck macht er auch auf mich. Ich bin mir nicht sicher, inwiefern er bei grossen Projekten mit aberhunderten von Entitäten wirklich bequem durchführbar ist. Aber er ist bestimmt nicht schlecht; ich werde damit experimentieren.
Hallo !
erst mal ein Lob, dein Blog hat wirklich interessante Einträge, ich hoffe du machst aktiv weiter…
Ich halte deinen Ansatz für sehr gut, hast du mittlerweile Erfahrungen sammeln können ?
Hi Wolfgang,
ich danke dir für die Blumen. Ich habe weitere Monate programmiert, bin dabei aber nie mehr an diesen Ansatz gekommen. Der Ansatz tönt zwar sehr gut, und ist vom akademischen Standpunkt her sehr sauber (wie das letzte Zitat im Artikel bereits sagt). In kleinen Umgebungen entsteht ein sehr grosser Overhead, wenn man einen kleinen Datenzugriffslayer mit ein wenig Logik in drei Assemblies, anstatt einem einzigen, plegt. Ich werde mich in der nächsten Zeit wohl intensiver mit dem Entity Framework auseinandersetzen, dass mit .NET 3.5 SP1 eingeführt wurde, und parallel dazu den Klassiker zu Design Patterns durcharbeiten. Oft ist diese Lösung zwar sehr, sehr flexibel (die sprichwörtliche beliebige Austauschbarkeit ist eigentlich nur über diese Variante wirklich erreichbar), jedoch für Projekte meiner Schuhgrösse zu kompliziert, um sich auszuzahlen.
Grüsse
Matthias