Verwendung von Common-Domain-Logikstrukturen bei .NET-Anwendungen

Die dritte Struktur zur Darstellung der Domänenlogik in einer Anwendung ist das Domänenmodell. Bei dieser Struktur wird die Anwendung als eine Menge miteinander in Beziehung stehender Objekte dargestellt. Die zentrale Eigenschaft dieser Objekte ist, dass – anders als beim Tabellenmodul – jedes Objekt auf eine Einheit (nicht unbedingt eine Datenbank-Tabelle) in der Datenbank abgebildet wird.

Mit anderen Worten: Jedes Primärobjekt stellt einen einzelnen Eintrag in der Datenbank dar und keine Eintragsgruppe und das Objekt koppelt die Daten des Objekts (seine Eigenschaften) mit seinem Verhalten (Geschäftslogik und Methoden und Ereignisse der Datenvalidierung). Weitere Objekte stehen eventuell für Kalkulationen oder ein anderes Verhalten. Letzten Endes erfordert dieser Ansatz mindestens die folgenden Voraussetzungen:

• Objektbezogene Abbildung: Da sich diese Struktur nicht auf das DataSet-Objekt oder gar auf Typed DataSet-Objekte bezieht, ist eine Abbildungscode-Ebene erforderlich. Derzeit bietet das .NET Framework keine integrierte Unterstützung für diese Ebene. Unterstützung findet man in der ObjectSpaces-Technologie, die mit dem Whidbey-Release von VS.NET herauskommen soll. Verfahren zur Durchführung dieser Abbildung werden im nächsten Artikel behandelt.
• Generierung: Da jedes Domänenmodell-Objekt auf eine Einheit in der Datenbank abgebildet wird, müssen die Objekte die Datenbankidentität innerhalb des Objekts speichern (das Objektsystem des CLR identifiziert jedes Objekt eindeutig auf der Grundlage seiner Adresse). Verschiedene Verfahren zur Generierung und Speicherung von IDs verwenden vom System zugewiesene Schlüssel, GUIDs und das Identity Field Pattern von Fowler.
• typisierte Auflistungsklassen:bjekte beim Domänenmodell intrinsisch auf eine einzelne Einheit abgebildet werden, wird die Darstellung von mehreren Objekten über Auflistungen gehandhabt. .NET Framework-Entwickler können daher stark typisierte Auflistungsklassen erstellen, um die Darstellung mehrerer Domänenobjekte zu bewältigen.

Das Endergebnis eines Domänenmodells besteht darin, dass die Anwendung im Laufe einer Anwendersitzung viele einzelne und miteinander in Beziehung stehende Objekte verwaltet (durch Summenbildung). Obwohl dies vielleicht verschwenderisch scheinen mag, macht die Effizienz des CLR bei der Verwaltung von Objekten das Domänenmodell zu einem sinnvollen Ansatz. Ein solcher Ansatz würde allerdings in der COM-Welt keine effiziente Lösung darstellen.

Um ein Objekt zu erstellen, das in einem Domänenmodell verwendet wird, bietet es sich an, der Layer SuperType-Struktur zu folgen. Unter Verwendung dieser Struktur kann ein Architekt eine Basisklasse entwickeln, von der auf alle Domänenobjekte vererbt würde, wie dies in Abbildung C dargestellt ist.

Abbildung C: Domänenmodell

Der Vorteil des Domänenmodells liegt darin, dass die für eine bestimmte Operation benötigte Logik lose über die Objekte hinweg gekoppelt ist statt in einer einzelnen Methode enthalten zu sein. Diese Struktur versucht, die Anwendung als Gruppe miteinander in Beziehung stehender Objekte darzustellen.

Welche Struktur ist die beste?

Welche architektonische Struktur sollte also in einer .NET Framework-Anwendung verwendet werden? Alle drei besprochenen Strukturen haben Vor- und Nachteile:

• Transaktionsskript: Dieses Konzept ist am einfachsten zu verstehen und am schnellsten zu entwickeln. Weniger Abstraktionsebenen bedeuten ein Potenzial für duplizierten Code sowie eine schwierigere Nachbearbeitung, wenn sich die Anforderungen ändern.
• Tabellenmodul: Diese Struktur bietet in puncto Komplexität einen guten Mittelweg zwischen den anderen beiden. Sie passt sehr gut zum DataSet in ADO.NET, ist aber nicht vollständig objektorientiert.
• Domänenmodell: Dies ist die flexibelste Option und die am stärksten objektorientierte. Sie hängt nicht so stark von der Public-Domain-Komponente von ADO.NET ab und ist somit von Änderungen an ADO.NET bei neueren Releases des .NET Framework isoliert.

Der Datenzugriffscode wird in einem späteren Artikel behandelt werden.