Thomas Darimont
Erfahrenes Mitglied
Hallo!
ApplicationServers (Beispielsweise bei intensiver Verwendung von Hibernate, etc.) Aber in der Regel gehts natürlich schon ein ganzes Stückschen flotter
Desweiteren sind IMHO gerade für Integrationstests bestimmte Infrastrukturen notwendig (Beispieliele: Datenbank muss vor dem Test mit passenden Testdaten initialisiert werden (-> DBUnit) anschlißend muss wieder aufgeräumt werden, zum Testen des Login Moduls muss der LDAP Server muss verfügbar sein, der Third Party Webservice muss zur verfügung stehen, und und und... auch wenn man sich hier mit exzessivem Mocking helfen kann bleibt man jedoch manchmal nicht von sämtlicher Infrastruktur verschohnt)
Btw. Es sind Subklassen von TestCase ;-)
Das Spring Anwendungen skalieren würde ich eher in anderem Kontext sehen, nämlich in der Unterstützung der Implementierung von Verteilten System über das einfache Remoting, und die zahlreichen Clustering-Möglichkeiten über Thirdparty Produkte (GigaSpaces, JGroups etc.).
Btw. Spring kann natürlich auch in einem normalen J2EE Server wie JBoss laufen und bietet auch support für EJBs. -> Die Entscheidung etwas zwingend mit EJB Implementieren zu wollen schließt den Einsatz von Spring natürlich nicht aus ;-)
Gruß Tom
Na ja, bei größeren Anwendungen braucht das starten des ApplicationContexts fast genauso lange wie der start eines
ApplicationServers (Beispielsweise bei intensiver Verwendung von Hibernate, etc.) Aber in der Regel gehts natürlich schon ein ganzes Stückschen flotter
Desweiteren sind IMHO gerade für Integrationstests bestimmte Infrastrukturen notwendig (Beispieliele: Datenbank muss vor dem Test mit passenden Testdaten initialisiert werden (-> DBUnit) anschlißend muss wieder aufgeräumt werden, zum Testen des Login Moduls muss der LDAP Server muss verfügbar sein, der Third Party Webservice muss zur verfügung stehen, und und und... auch wenn man sich hier mit exzessivem Mocking helfen kann bleibt man jedoch manchmal nicht von sämtlicher Infrastruktur verschohnt)Btw. Es sind Subklassen von TestCase ;-)
Wie ich bereits sagte, der Interception Mechanismus von EJB 3.0 ist quasi "the other way around" im Gegensatz zu traditionellem AOP mit einem Around Advice.
Ich würde eher sagen, dass man Spring in beliebigen Ausbaustufen in der Anwendung einsetzen kann. Beispielsweise kann man sich auch nur dem IoC bedienen oder man benutzt den sukzessive nach und nach den kompletten Spring-Stack. Dies erlaubt es Spring Schrittweise einzusetzen und so die Technologie "sanft" in die Architektur einzuführen.
Das Spring Anwendungen skalieren würde ich eher in anderem Kontext sehen, nämlich in der Unterstützung der Implementierung von Verteilten System über das einfache Remoting, und die zahlreichen Clustering-Möglichkeiten über Thirdparty Produkte (GigaSpaces, JGroups etc.).
Das kann man mit normalen JEE 5 auch in ähnlicher Weise ;-) Viel interessanter finde ich hier die Vielfallt an zur Verfügung stehenden Remoting Methoden: RMI, RMI over IIOP, Springs HTTP Remoting, Webservices über Axis, Hessian, Burlap ode XFire etc. darüber hinaus ist es auch recht einfach eigene Remoting Stacks hinzuzufügen (haben wir gerade für JGroups gemacht).
Das Spring MVC Framework ist zur Implementierung der Präsentationsschicht (Web) einer Spring-Awendung ein guter Weg, jedoch sollte man auch erwähnen, dass es mit Spring Webflow noch eine Zusätzliches Framework gibt, mit dessen Hilfe man auch größere komplexe Page-Flows deklarativ in Form einer Statemachine modellieren kann, darüber hinaus gibts noch Support für Continuations und und und...
Insbesondere das Forcieren des Konzeptes gegen Interfaces zu Programmieren und konkrete Implementierungen in der Konfiguration zu verstecken macht die Anwendung sehr flexibel hinsichtlich Erweiterbarkeit und Wartbarkeit. Weiterhin erlaubt Spring eine Art Komponentisierung des Gesamtsystems, so dass man nach und nach aus kleinen Komponenten (Spring-Beans) größere komplexere Komponenten zusammenstöpseln kann.
Also ich würde das eher Präsentationsschichtunabhängigkeit nennen... und die bekommt man natürlich auch nicht automatsich ;-) Man muss natürlich durch geschickte Implementierung der einzelnen Schichten diese weitestgehend unabhängig voneinender machen, Spring bietet hier durch Best Practices viel Unterstützung, jedoch muss der Entwickler immer noch wissen wie man diese richtig Umsetzt.
....SpringIDE, Integration in Zahlreiche Applikationserver (Spring stellt beispielsweise die Basis der JEE 5 Implementierung im BEA Weblogic dar). Weiterhin gibt es starke Unterstützung in der Industrie durch namhafte Firmen wie BEA, Oracle und IBM.
Hochgradig Verteilte Systeme sind IMHO noch der einzige Anwendungsfall in denen EJB noch als Implementierungsbasis in betracht gezogen werden sollten, ansonsten würde ich immer zu Spring greifen.
Btw. Spring kann natürlich auch in einem normalen J2EE Server wie JBoss laufen und bietet auch support für EJBs. -> Die Entscheidung etwas zwingend mit EJB Implementieren zu wollen schließt den Einsatz von Spring natürlich nicht aus ;-)
Gruß Tom
