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.
