Hier kann man einen Link auf einen Blog finden, in dem der Autor sich darüber auslässt, dass Spring keine gute Idee ist. An dieser Stelle muss ich Ramstein zitierten: "Ich bin enttäuscht. Total enttäuscht." Worauf ich warte, ist eine fundierte Kritik an Spring, denn auch Spring wird nicht das letzte Framework sein. Und wenn man die Schwächen kennt, kann man anfangen Verbesserungen zu erarbeiten. Der vorliegende Artikel ist aber leider keine Basis dafür:
- J2EE ist nicht schlecht. Es ist eine gute Basis für Enterprise Anwendungen. Spring ist eine Abstraktion über J2EE. Daher gibt es eher Synergien zwischen J2EE und Spring als einen Gegensatz. Entsprechend ist es auch nicht richtig, dass Spring Leute bzgl. J2EE hochnäsig sind.
- Die JavaDocs sind sehr tatsächlich ausführlich. Meiner Erfahrung nach ist das aber ein Feature. Man findet praktisch immer eine Antwort auf ein Problem in den JavaDocs. Da sie in der IDE integriert sind, ist das ein wirklicher Vorteil. Man bekommt auch Antworten auf Fragen wie "Wo wird Transaktions-Verschachtelung unterstützt?" und das recht schnell.
- Ja, die Spring-Konfiguration ist Spring-spezifisch. Darum geht es aber nicht. Es geht darum, dass der Java-Code unabhängig von Spring ist. Dadurch ist eine Wiederverwendung auch ohne Spring machbar. Eine von der Dependency Injection Implementierung unabhängige Dependency Injection Konfiguration gibt es auch nicht.
- Die Abhängigkeiten werden per Spring IDE zur Entwicklungs-Zeit gecheckt und sonst (meistens) beim Startup der Anwendung. In der Praxis ist das Typisierungsthema keins. Und wenn man typsicher sein kann, kann man auch Autowiring nach Typ benutzen. Außerdem ist Java auch nicht so typsicher, zumindest <1.5.
- Nein, man schreibt nie eine ID eines Spring-Objekts im Code. Weil Dependency Injection überall hinreicht. Auch in die GUI, Web-Layer usw. Die Vermutung, dass man Spring Bean IDs oft im Code benötigt, ist einfach realitätsfremd. Es gibt ganz wenige Ausnahmen (EJB 2 Wrapper für Spring zum Beispiel).
Und so weiter.
Was ich vor allem Schade finde: Spring hat 3 Elemente: Dependency Injection, AOP und die API-Abstraktion. Wer Dependency Injection nicht mag oder die Spring Implementierung nicht mag, soll halt was anderes nutzen. Der Rest von Spring kann dann immer noch verwendet werden. Im Blog geht es aber nur um Dependency Injection und dann auch nur darum, dass die Spring Version von Dependency Injection angeblich nichts taugt (wie übrigens angeblich auch die von Pico Container nichts taugt). Ich bin nicht dieser Meinung, aber selbst dann kann man den Rest von Spring trotzdem verwenden. Und wer z.B. JMS oder JDBC ohne Spring verwendet, macht sich einfach unnötig das Leben schwer.
Fazit: Sehr schade. Ich bin auf der Suche nach wirklichen Problemen mit Spring. Nur dadurch kann ein Framework wachsen, denn wenn die Probleme bekannt sind, kann man anfangen, sie zu beseitigen. Dieser Blog-Eintrag hilft leider nicht weiter. ¶ 15:30
