Domänenmodell und Objektorientierung

Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software. (Eric Evans: Domain Driven Design)

Wie das Zitat schon sagt: Das Rückgrat einer Anwendung ist das Domänenmodell. Dieses Modell beschreibt die Datenstrukturen, die mit dieser Anwendung verwaltet werden sollen. Leider verkommen die Klassen, die dieses Modell repräsentieren immer mehr zu inhaltsleeren POJOs. Sie bestehen fast nur noch aus Getter- und Setter-Methoden und den zugehörigen Feldern. Martin Fowler hat das hier als Anemic Domainmodel beschrieben.

Stellen Sie sich vor, Sie haben ein Objekt Bestellung. Es wäre wünschenswert, dass dieses Objekt auch eine Methode zum Abschicken der Bestellung hat. In einer typischen Anwendung übernimmt diese Funktionalität allerdings eher ein Service.

Um so etwas zu ändern, braucht dieses Bestellobjekt eine Referenz auf die Datenzugriffsschicht. Das können Klassen übernehmen, die das DAO-Pattern implementieren. Solche DAOs sind zustandslos, müssen also nicht bei jedem Zugriff neu initialisiert werden.

Evaluierung der Möglichkeiten

Wie bekommt man dieses DAO in das neu initialisierte Objekt? Die Schwierigkeit besteht darin, dass immer wieder neu erstellte Objekte eine Referenz auf eine bestehende Instanz bekommen. Als Möglichkeiten gibt es:

• Statische Methodenzugriffe
• Singleton-Pattern implementieren

Beide Möglichkeiten sind eher schlecht. Ein K.O.-Kriterium ist dabei die fehlende Testbarkeit. Besser wäre es, eine Lösung zu finden, die mittels Dependency Injection die benötigten Referenzen setzt.

Denkt man an Dependency Injection, dann denkt man auch an Spring. Allerdings löst Spring dieses Problem nicht Out-of-the-box. Mit Spring werden normalerweise Klassen verwaltet, die nur einmal zur Laufzeit initialisiert werden müssen.

Exkurs: Anatomie einer Spring-Anwendung

Warum ist das so? Um das zu erklären, müssen wir uns gemeinsam eine typische Spring-Anwendung ansehen. Spring ist ein nicht invasives Framework. Das bedeutet, es erfordert nicht das Implementieren von Interfaces oder das Erben von Superklassen. Somit kann die Anwendung mit Java-Bordmitteln erstellt werden. Spring umgibt die Anwendung dann als Container und konfiguriert diese mit XML oder Annotations (Abb. 1).

Abb. 1: Spring als Container für Anwendungen

Dabei sind die Spring Beans – die Klassen, die von Spring verwaltet werden –verwaltete Singletons, d.h. Klassen werden einmalig erzeugt und diese Instanz immer wieder verwendet. In Listing 1 sehen Sie das Prinzip veranschaulicht. Der OrderService benötigt ein Datenzugriffsobjekt (DAO). Dieses DAO ist zustandslos. Somit reicht eine Instanz. Spring verwaltet diese Instanz und injiziert sie den anfragenden Objekten – in diesem Fall der OrderService. Eine Einschränkung dabei ist, dass das anfragende Objekt ebenfalls eine Spring Bean sein muss.

Natürlich ist es auch möglich, ein Objekt bei jedem Aufruf neu instanziieren zu lassen. Allerdings muss auch hier der Aufrufer eine Spring Bean sein.

1. public class OrderService{
2. @Resource
3. private OrderDao orderDao ;
4. }

Kann denn Spring gar nicht helfen?

Auf den ersten Blick sieht es tatsächlich so aus, dass Spring uns bei unserem Problem nicht helfen kann. Aber dieser Artikel wäre völlig sinnlos, wenn es nicht doch einen Lösungsansatz gäbe.

Seit Spring 2.0 gibt es @Configurable Annotation. Mit dieser Annotation können Sie Klassen annotieren, die über das new-Schlüsselwort erzeugt werden, aber von Spring als Spring Beans behandelt werden sollen.

1. @Configurable
2. @Entity
3. public class Order{
4. @Resource
5. private OrderDao orderDao ;
7. public void saveOrder() throws SaveException{
8. orderDao.saveOrder(this) ;
9. }
10. }
12. @Repository
13. public class OrderDao{
14. public Order findOrderById(Long id){
15. …
16. }
17. }

In Listing 2 sehen Sie zwei Klassen, die miteinander in Beziehung stehen. Die Entität Order benötigt die Datenzugriffskomponente OrderDao, um die Bestellung zu speichern.