Dariusz quatscht

PingBack from http://asp-net-hosting.simplynetdev.com/projekt-blog-poll-%e2%80%93-entity-framework-revisited-und-die-folgen-bisher/

Hi Darius,

Ich finde, du bekommst zu wenig Feedback für deine Mühen, hier also mein Beitrag!

Zunächst mal: ich finde deine Screencasts sehr gelungen, mach auf jeden Fall weiter :-)

Einige Anmerkungen zu den Repositories hätte ich noch. Zum einen muss ich sagen, dass ich den von dir beschriebenen Ansatz (mapping zwischen EF Model und Domain Model) nicht so optimal finde: das Mapping ist wieder zusätzlicher Code, der gewartet werden muss. Kommt z.B. eine Property hinzu, muss auch dieses Mapping angepasst werden. Setzt man zudem noch data transfer objects ein, um Daten "mundgerecht" an die UI Schicht zu geben, kommt man aus dem mappen nicht mehr raus...

Im Sinne des Single Responsibility Principle wäre das Mapping wohl in eine eigene Klasse (ähnlich eines DTO assemblers) auszulagern, wobei ich verstehe, dass das ggf. den Rahmen eines Screencasts sprengt.

Ich verstehe natürlich, dass du das Mapping machen musst, um das Domain Model unabhängig vom Persistence Layer zu halten. Und gerade deshalb fände ich es höchst interessant, wenn du auch NHibernate als ORM Middleware mit einbeziehen würdest, da damit ein solches Mapping entfallen würde.

Noch eine kleine Anmerkung, auch wenn das schon in Richtung Erbsenzählerei geht: genau genommen schreibst du eher Data Access Objects statt Repositories. Laut Evans bieten Repositories ausschließlich Zugang zu Aggregate Roots. PossibleAnswer ist aber mMn kein Aggregate Root.

Kürzlich gab es eine sehr Interessante Kontroverse bzgl. Repositories auf Ayendes blog (http://ayende.com/Blog/archive/2009/04/17/repository-is-the-new-singleton.aspx). Und er hat nicht Unrecht: Repositories tendieren dazu, recht hässliche Biester zu werden. Ich habe versuchsweise in einem neuen Projekt bewusst auf Repositories verzichtet und stattdessen die von Ayende beschriebenene Vorgehensweise befolgt (NHibernates ISession direkt verwenden in Kombination mit Query Objekten). Und ich muss sagen, dass ich damit sehr zufrieden bin. Statt die ISession in Unit Tests zu mocken, verwende ich das "echte" NHibernate mit einer SQLite in-memory Datenbank. Auf dem ersten Blick scheint das gegen die gewünschte Isolation in Unit Tests zu gehen, bei näherer Betrachtung ist es aber sehr sinnvoll, da sich die Entitäten aus der Datenbank eben anders verhalten als einfache Speicherobjekte (Proxies, Lazy Initialization).

So viel von meiner Seite. Ich hoffe nicht zu "nörgelig" rübergekommen zu sein. Es liegt nicht in meinem Interesse, irgendetwas schlecht zu reden.  Wie gesagt, ich mag die Screencasts.

Viele Grüße,

Andre

Und sorry, dass ich deinen Namen falsch geschrieben habe :-)

Darf ich übrigens Fragen, wie du deine Videos aufzeichnest und kodierst? Die Qualität ist ja wirklich ausgezeichnet.

Das Problem mit der Serialisierung des Domain Models existiert natürlich, hat für mich aber praktisch wenige bis keine Auswirkungen.

Architektonisch gesehen habe ich im Kern das Domain Model mit der Geschäftslogik. Drumherum wird dieses Model gekapselt durch einen Service Layer, der eine Schnittstelle zum Domain Model bietet für UI, Session, anderen Prozessen etc. Die Nachrichten, die über diese Schnittstelle geschickt werden, sind Data Transfer Objekte (oder natürlich primitive Typen). Objekte meines Domain Models verlassen niemals(!) den Service Layer, weder in Richtung UI, noch in Richtung Session (wichtig im SessionState oder SqlServer Modus) noch in Richtung Remoting/WCF. Stattdessen erzeuge ich immer passende DTOs, die dann i.d.R. auch serialisierbar sind.

Natürlich muss ich auch hier mappen, aber im Gegensatz zu dem 1:1 EF<->Domain Model Mapping erfüllt das DTO<->Domain Object Mapping zusätzliche Funktionen: z.B. kann man hier den Objektgraphen abflachen (zur Wahrung des Law Of Demeter), nur bestimmte Daten mappen (Sicherheitsaspekt, Minimalisierung des Netzwerk Traffics) und gezielt weitere Roundtrips zur DB auslösen oder vermeiden. So kann ich vermeiden, dass beispielsweise in der UI auf eine Proxy-Eigenschaft zugegriffen wird, die ggf. SELECT 1 + N Probleme bzw. Probleme mit geschlossenen Sessions verursachen. Übrigens ist gerade das der Grund, warum ich bei den Unit Tests keine Mock Session (order Repositories) verwende, sondern „echte“ In-Memory-Databases.  Für das Mapping selbst benutze ich Assembler Klassen.

Wie du siehst, komme ich auch nicht um ein Object<->Object Mapping herum, allerdings kann ich dieses Mapping positiv einsetzen, um mehr Kontrolle zu erlangen. Außerdem ist dieses Mapping unabhängig vom Persistenz-Framework.

Gerade bei der Serialisierung kommt man in der Praxis an diesem Schritt eh nicht ganz vorbei: denn selbst wenn das Domain Model selbst serialisierbar ist, woher weiß ein Objekt, wann der Objektgraph wie weit serialisiert werden muss?