1. Spring Roo (mit SpringSource Tool Suite)
2. Large Applications – Infrastructure
- Infrastructure-Konfiguration von übriger Konfiguration trennen (eigene XML-Datei, PropertyPlaceholderConfigurer); besser keine Default-Werte verwenden
- Unterschiedliche Infrastructure-Beans (lazy-init) über einen Alias (mit Placeholder im Namen)
- Spring 3.1: statt dessen Profiles verwenden
- Für In-Memory-Databases: <jdbc:embedded-database/> <jdbc:script/> (eher nicht verwenden, da sich Im-Meory-DBs oft anders als richtige DBs verhalten)
Ziel: horizontal (Layers) und vertikal (Slices) strukturiertes System (Slices sind wichtiger!) - vgl. Slides
- Strukturieren mit Naming Conventions: com.acme.${slice}.[dao|domain|service|web] – Problem: Sichtbarkeit
- Component-Scan mit Naming-Convention (ohne @Service-Annotation):
- AspectJ Dependency Management (z.B. verbotene Aufrufe zwischen den Schichten verhindern) mit @DeclareError (als Alternative zu Sonargraph/Structure101)
- Strukturieren mit Annotations (@Service, @Repository...)
- Meta-Annotations statt eine Klasse mehrfach zu annotieren
- Strukturieren mit XML
- ein eigenes Context-XML je Layer/Slice
- Nachteil: keine Sichtbarkeitseinschränkungen, keine expliziten Abhängigkeiten
- Idee: jede Komponente als Jar-File mit fixem Context-XML, merge mit "classpath*"
- Idee: Layering oder Slices mittels ApplicationContext-Hierarchien
- Spring Dynamic Modules (OSGi)
- <osgi:service>, <osgi:reference>
- Eher nicht praktikabel (sehr komplex)
- Spring Java Config