Schon seit einiger Zeit verwende ich Spring Security (format ACEGI Securtiy) um einfach Authentifizierungs und Authorisierungsprobleme für Webanwendungen zu lösen. Mit der Version 2.0 gibt es jetzt auch eine etwas einfachere Konfigurationsmöglichkeit, allerdings war es für mich immer schwierig gezielt einzelne Implementierungen zu ändern/ zu ersetzen.
Mit dem Problem schien ich nicht allein zu sein, im diesem Blog habe ich einen Artikel wie man Spring Security anpasst und ergänzt gefunden, der sehr ausführlich und anschaulich beschreibt was man konfigurieren muss.
In der letzten Woche hatte ich eine interessante Diskussion mit einem Arbeitskollegen. Ausgehen von einem konkreten Problem kamen wir nach und nach zu einer Recht fundamentalen Diskussion über das Pro und Contra des Model View Controller (MVC) Ansatzes für Web Anwendungen.
Nachdem ich anfangs fast automatisch in die übliche Schema gefallen bin, alles bisherige zur verteidigen, wurde mir Schritt für Schritt bewußter, dass ich das ganze nie wirklich hinterfragt hatte. Spätestens seit den Zeiten von Struts 1.x war MVC für mich eigentlich gesetzt und im Laufe der Zeit hat es sich so sehr festzementiert, dass ich mir Web Entwicklung ohne MVC fast nicht mehr vorstellen kann.
Nach der Diskussion habe ich dann mal im Web recherschiert, in der Tat scheinen 99% aller Java Web Frameworks (und davon gibt es ja nun wahrlich genug) auf dem MVC Pattern zu beruhen und Kritik oder alternative Ansätze gibt es wenig. So musste ich eine ganze Weile suchen bis ich diesen Blogeintrag entdeckt habe.
Sind wir mal ehrlich, alle die wir schon einmal eine Web Anwendung geschrieben haben wissen: Es gibt nur eine View: HTML. Alle Beispiele für alternative Ausgabekanäle (WAP; XML…) sind konstruiert oder haben ein sehr begrenztes Anwendungsszenario. Zudem sind die Anforderungen die das Netz mit sich bringt oft so speziell dass auch der Controller ohne Web keinen Sinn macht. Also können wir die ganze Diskussion über Austauschbarkeit und Wiederverwendbarkeit mal getrost der Wissenschaft überlassen. Bleibt noch die Wartbarkeit, bekanntlich soll der Code ja leicht zu ändern und gut zu pflegen sein. Aber sauber organisierter Code muss nicht gleich MVC heissen, im Gegenteil manchmal steht MVC der Wartbarkeit sogar entgegen.
Das soll jetzt keine Predigt gegen MVC an sich sein, aber jedes Muster sollte man nur dann anwenden wenn es passt. Mit der Zunahme von Mashups und anderern Aggregationstechniken, einem starken Innovationsdruck von Seiten der Skriptsprachen her und den immer dynamischeren Applikationen (Web 2.0) darf MVC kein heiliger Gral sein. Für mich ist MVC kein Selbstzweck, vielleicht darf es manchmal noch einfacher sein, schließlich ist ja bekanntlich gut, gut genug.