Sup!
na ja, als ich das ganze das erste mal gehört habe, hab ich auch nicht viel davon gehalten. Mittlerweile hab ich einige Bücher und ein paar Beispielimplementierungen gesehen und bin von derartig strukturierten Systemen einigermaßen überzeugt. Die Trennung von Inhalt und Darstellung, das predigen wir hier doch alle jedes Mal auf's neue mit CSS und "sauberem" HTML. Nun geht das ganze doch nur noch einen Schritt weiter: Wir trennen auch noch Verarbeitunsroutinen von den reinen Datenroutinen, in meinem Fall bedeuted das C# Klassen vs. Stored Procedures im SQL-Server. Es geht den SQL-Server weder was an, welche Fehler hier wann nach außen geworfen werden noch welche Checks und Meldungen der Reihe nach ablaufen bevor irgendein Vorgang abläuft. Anders herum kann es der C#-Klasse relativ egal sein, ob ein Feldwert jetzt über dies oder jenes SQL-Statement rausgekommen ist, das ist Sache des Daten(-bank)-Modells in dem die Daten langfristig liegen, was nichts mit der Verarbeitung zu tun hat.
Ist 3-Tier ein IT-Schlagwort? Sicherlich.
Macht 3-Tier Sinn? IMHO ebenfalls sicherlich.*
Ich hab' nurmal gesehen, wie bei einem kleineren Projekt Leute so ein System designt haben; Datenstruktur, Geschäftslogik und Präsentationsschicht hingen dabei so weitgehend zusammen, dass sie immer, wenn Ihnen eingefallen ist, dass auf Ebene der Präsentationsschicht noch etwas zusätzlich angezeigt werden sollte, alle drei Ebenen ändern mussten; das mag heute mit einem vernünftigen IDE und "Refactoring" nicht mehr so schlimm sein wie "damals"; ist aber dennoch nervig.
Sowieso ist Code-Reuse (warum sonst sollte man trennen) weitgehend ein Mythos, wenn man von Bibliotheken absieht.
Gruesse,
Bio
Never give up, never surrender!!!