Wenn es darum geht eine "normale” Webapplikation zu bauen, dann kommt man meist auf eine 3 Schichten Architektur heraus. Der meistgelesenste Blogeintrag dreht sich um diese Architektur, allerdings kommen bei mir immer mal wieder Zweifel auf, ob man nicht zuviel Aufwand in der DAL betreibt - immerhin gibt es tolle OR Mapper. Doch auch damit bin ich bereits auf die Nase gefallen und hab mich von dem Gebrauch dieser Linq2Sql oder Entity Framework generierten Model-Klassen distanziert. Ayende Rahien hat aber mal wieder meine Zweifel geweckt...
3-Schichten Architektur
Ayende selbst ist bekennender Fan von NHibernate (immerhin hat er es mitentwickelt) und mag auch das Repository Pattern wohl auch nicht mehr so.
Allerdings sind die Grundgedanken vollkommen nachvollziehbar. Die Grafiken stammen aus einem von Ayendes Posts. Der normale Aufbau wäre bei einer 3-Schichten Architektur so:
Der Ablauf sobald ein User z.B. auf einen bestimmten Eintrag auf einer Website klickt wäre so:
Ihn stört es, dass man durch Repositories noch eine weitere Abstraktionsebene aufbaut. In den meisten meiner Projekte hatten wir es auch so umgesetzt und in dem "Data" Layer noch einen ORM, wie z.B. Linq2Sql oder das Entity Framework benutzt.
Zu viel Abstraktion?
Die Frage die ich mir stelle: Lohnt sich der Aufwand (und die Kosten für den Kunden) den Data-Layer zu kapseln, wenn man ohnehin ein OR Mapper benutzt?
Kann man denn realistisch und mit vertretbaren Aufwänden überhaupt eine gescheites IUserRepository bauen? Ayende hat ein paar Punkte aufgezählt, warum die Kapselung eines Data Access Layers unnötig auch nicht wirklich umsetzbar ist. In einem weiteren Post geht er genau ein und zeigt anhand des Membership Providers (den ich persönlich für grausam erachte), dass es vergebene Mühe ist.
Durch die Kapselung wird es leichter mit Unit-Tests die Businesslogik zu testen!
Durch ein Projekt wo wir in der Businesslogik direkt Linq2Sql und das Entity Framework eingesetzt haben, war es äußerst mühsam bis unmöglich Unit-Tests zu schreiben. Daher war es für die Testbarkeit der Businessschicht enorm wichtig, dass man die DAL auch mocken kann. Allerdings sind die beiden OR/M ja nicht die einzigen .NET OR/M...
NHibernate
Ayende ging auch in einem Post auf das Mocking von NHibernate ein und wie man auch Unit-Tests abbilden kann.
Die große Frage (und warum ich diesen Post schreibe)
Mach ich mir das Leben selber kompliziert indem ich versuche die DAL zu kapseln? Nehm ich vielleicht einfach nur die falschen OR/Mapper? Ist NHibernate so toll und kann mir jemand ein tolles Beispielprojekt samt Unit-Tests zeigen? :)
Ist eine 3-Schichten Architektur am Ende immer erstrebenswert? (Achtung: Ich geh hier von einem 0815 Webprojekt aus und zählen den OR/Mapper nicht als direkte Schicht, sondern ich würde direkt in der Business-Schicht NHibernate arbeiten. Dass es im Embedded Bereich andere Spielregel gibt ist mir klar ;) )
