Keep it simple! YAGNI!
Dauerbrenner auf dem Blog ist der Artikel HowTo: 3-Tier / 3-Schichten Architektur. Allerdings hatte ich schon einige Zeit Zweifel (Ist eine 3 Schichten Architektur mit eigener DAL immer empfehlenswert?)daran, dass dieses Standardvorgehen immer der richtige Weg ist. Vor ein paar Tagen hatte ich dann einen interessanten Blogpost gelesen, welcher in die gleiche Richtung geht: Keep your code simple!
Von Spaghetti-Code zum Lasagne-Code
Jeder Entwickler hat verstanden, dass es nicht gesund ist 1000 Zeilen Code zu produzieren, welche nur für eine Funktion gut sind. Die Trennung in Schichten kann allerdings auch in das andere Extrem schlagen: Lasagne Code. Dutzende Schichten Code, ohne das sie wirklich was machen. Einfach nur, damit die Objekte von Schicht zu Schicht wandern.
KISS & YAGNI
Bevor man grundlos eine 3-Schichten Architektur wählt, sollte man sich die Frage stellen: Wozu brauch ich dies eigentlich?
Wozu Repository-, Business und Presentation-Layer? Wenn man wirklich zwei Frontends (WebApp und Fat-Client), dann mag das clever sein – aber meisten braucht man es nicht (YAGNI). Je mehr Schichten, desto langsamer wird die Entwicklung. Da eine Schnittstelle definieren und dort noch ein Property hinzufügen und dieses dann implementieren und das nur, weil man plötzlich auf der Website ein Feld mehr anzeigen will.
Mh… und wie könnte eine Lösung aussehen?
Ich bin mittlerweile recht pragmatisch geworden und hab auch keine so große Schmerzen mehr die Datenabfrage direkt im Controller (im ASP.NET MVC Sinne) zu machen.
Erst wenn ich die Abfrage doch noch woanders brauche, mach ich mir intensivere Gedanken ob man dies nicht in eine Art “Query”-Klasse auslagern kann.
Schreibende Vorgänge würde ich anfangs ebenso behandeln – erst wenn man es an mehreren Stellen braucht, würde ich dies in “Command”-Klassen auslagern.
Ziel davon: Copy/Paste sollte natürlich nach wie vor vermieden werden – die Businesslogik doppelt zu halten ist der falsche Weg.
Und wie steht es mit Unit-Tests?
Der einzige Knackpunkt an der Sache ist, dass man ohne Interfaces etc. natürlich schlechter mocken kann. Allerdings bin ich mir mittlerweile auch unsicher, welchen Wert diese Unit-Tests haben. Dutzende Tests, welche gegen Mocks gehen und 5 Zeilen Code testen.
Integrationstests, welche die gesamte Applikation testen, sind am Ende “aussagekräftiger” – dies kann z.B. über eine SQLLiteDb erfolgen oder man geht gegen die richtige (aber langsame Datenbank) etc. Bei einem kleinen Projekt, welches keine großen Abhängigkeiten hat, sollte dies im Bereich des machbaren liegen. Je größer die Backendsysteme, desto eher muss man sich einen Kopf darum machen, wie man das am Ende testen möchte.
“Poor-Mans CQRS”
CQRS ist ein nettes Konzept, welches die Trennung von Queries (Abfragen) und Commands (Schreibende Aktionen) vorsieht (und noch weit mehr).
Daniel Lang (Autor vom Blogpost “Keep your code simple!”) hatte für seinen Ansatz den Begriff “Poor-Mans CQRS” gewählt – gefällt mir 
Was am Ende zählt…
Am Ende des Tages muss immer eine funktionstüchtige Software rauskommen. Die Software sollte ihren Zweck erfüllen und es nützt nichts wenn man immer “streng nach Vorschrift” entwickelt – “es kommt halt drauf an…”.
TL;DR
Bevor man anfängt sich dutzende Schichten zurecht zu bauen, um auch alles mit Mocks und Unit-Tests ausstatten zu können sollte man sich die Frage stellen: Brauch ich das überhaupt? Was ist das Ziel? Vermeidet trotzdem Copy/Paste und lagert Sachen nach dem Prinzip “CQRS” aus – Queries für lesende Sachen und Commands für Aktionen.
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Daniel Lang
5. November 2011
Hallo Robert,
Schön, dass dir mein Post gefallen hat.
Das mit dem Testen ist tatsächlich ein Problem wenn man wirklich streng jede einzelne Controller-Action testen möchte, denn auch SQLite Tests laufen vergleichsweise langsam. Ich habe das Problem aber nicht, weil ich Actions nicht teste, wenn diese nichts nennenswertes beinhalten. Für den Fall, dass man RavenDB verwendet, stellt sich das Thema überhaupt nicht weil es schnell und einfach ist einen EmbeddableDocumentStore zu verwenden – hier auch dann nicht faken, wenn ich Interfaces hätte.
Aber wie du schreibst,… kommt halt immer drauf an.