Im Sinne von Domain Driven Design bevorzuge ich Business Objekte in denen die Business Logik enthalten ist. Es handelt sich also nicht um reine Datenobjekte ohne Verhalten. Die enthaltene Business Logik will ich natürlich automatisiert testen. Mehr noch, ich will sie test-first implementieren können.
Andererseits sollen die Business Objekte durch einen Object Relational Mapper persistiert werden. Daraus ergibt sich unmittelbar die Frage wie gut diese beiden Anforderungen zusammen passen. Behindert der Object Relational Mapper beispielsweise meinen test-first Ansatz? Muss ich aufgrund des Mappers bestimmte Implementierungsregeln einhalten? Im folgenden möchte ich Anforderungen beschreiben die ich an einen Object Relational Mapper stelle.
Inspiriert zu diesem Beitrag wurde ich übrigens durch diesen Beitrag von Jeremy D. Miller in der ALT.NET Mailingliste. Weitere Informationen zu Object Relational Mapping (ORM) gibt es hier.
Keine Abhängigkeit der Business Domain Klassen vom Object Relational Mapper
Um meine Business Domain Klassen testen zu können muss ich Objekte der Klasse problemlos erzeugen können. Dabei möchte ich in den Tests auf keinen Fall gezwungen sein den Mapper zu berücksichtigen. Meine Business Domain Objekte sind POCO, Plain old CLR objects. Testdriven development (TDD) bedeutet für mich dass ich die Business Objekte mit ihrer jeweiligen Logik unabhängig vom Mapping implementieren kann. Je nach Projekt kann es erforderlich sein mit der Implementierung der Business Domain zu beginnen bevor die Entscheidung für einen Mapper gefallen ist.
Folgerung: der Mapper darf mich nicht zwingen meine Business Domain von einer Basisklasse abzuleiten die der Mapper vorgibt. Ferner möchte ich nicht gezwungen sein ein Interface des Mappers zu implementieren.
Keine direkte Abhängigkeit vom Datenbankschema
Unabhängig davon ob bereits ein Datenbankschema vorhanden ist (z.B. weil bereits Anwendungen existieren die dieses vorgeben) sollen meine Business Objekte keine direkte Abhängigkeit vom Datenbankschema haben. Damit meine ich, dass die Spalten einer Tabelle nicht zwangsläufig 1:1 als Properties einer Klasse auftauchen müssen und umgekehrt die Eigenschaften der Klassen nicht 1:1 in Datenbankspalten abgebildet werden müssen.
Die Business Domain Objekte entwickeln sich aus der Business Logik. Ziel ist ein leistungsfähiger Business Layer. Die Anforderungen an die Business Domain treiben die Entwicklung der Objekte und beeinflussen Designentscheidungen, nicht Überlegungen zum Datenbankschema.
Mapper die aus einem Datenbankschema Klassen generieren scheiden damit aus. Datenbankschema und Business Domain müssen sich unabhängig voneinander entwickeln können, der Mapper muss so flexibel sein dies zu ermöglichen.
Fazit
NHibernate erfüllt meine Anforderungen und ich setze es seit langem erfolgreich ein. Was derzeit fehlt ist eine LINQ to NHibernate Implementierung. Die vorhandene Implementierung ist leider noch längst nicht fertig.
LINQ to SQL ist für mich übrigens definitiv keine Alternative. Allein die Dirty Erkennung über generierten Code und partial methods halte ich für den völlig falschen Weg.
Technorati-Tags:
ORM,
NHibernate
