Sehr geehrte Forum-Mitglieder: Ich bin frustriert...
Seit geraumer Zeit bin ich als Freelancer für eine kleine Abteilung eines großen Konzerns tätig. Wir entwickeln Planungssoftware für Teilebedarfe der Produktion. Als ich mir die Architektur genauer anschaute, traute ich meinen Augen nicht. Die Schnittstelle zum Rich-Client, die der Server bereitstellt, besteht aus 6 Methoden:
Grundsätzlich gefallen mir die generischen Methoden zum Laden relativ gut, auch wenn sie ein wenig Granularität vermissen. Aber was aus meiner Sicht absolut fragwürdig ist, ist die Methode saveOrUpdate. Nochmals zur Erinnerung: Diese Methode befindet sich auf dem Rich-Client. Einen weiteren Kick bekommt dieses Design, wenn man sich die Delegationen dieser Methode genauer anschaut. Im Grunde wird über alle Schichten bis zu der Hibernate-Persistenz delegiert, welche schlussendlich ein saveOrUpdate durchführt. Die technologischen Schichten sehen wiefolgt aus:
Da auf dem Appl-Server nur generische Elemente existieren, ist die Business-Logik komplett im Client. Die "Fachklassen" sind Beans ohne Logik, mal davon abgesehen, dass es Hibernate-gemappte Objekte sind, die durch die Weltgeschichte gereicht werden.
Nach erbitterten Diskussionen, kamen einige inhaltliche Zugeständnisse, die aber den generellen Ansatz verteidigen und vor allem zu sehr seltsamen Implementationen führen.
Eine weitere Sache ist, dass konzeptionell Lost-Updates nur in besonderen Situationen abgefangen werden sollen. Eine generelle Vorgehensweise gibt es nicht.
Im letzten Monat wurde ein Modul entwickelt, welches auf der Seite des Clients Transaktionen suggeriert. Es gibt eine sogenannte Kontext-Klasse, über die Objekte angefordert angefordert werden können. Die Original-Beans werden gekapselt und mit einem Dirty-Mechanismus dekoriert. Schlussendlich wird auch hier eine Methode mit dem Namen "saveOrUpdate" aufgerufen, die nicht nur ein einziges Objekt überträgt, sondern alle neu erzeugten und geänderten und für jedes einzelne Objekt ein Hibernate-saveOrUpdate aufruft. Seitdem sind alle DB-Constraints Defferable und werden bei Einleitung der Transaktion Deffered, weil man die Reihenfolge der Objekte nicht sicherstellen kann ...
Lange Einleitung, kurze Frage: Macht man das heute so???
Freue mich über jeden Beitrag.
Seit geraumer Zeit bin ich als Freelancer für eine kleine Abteilung eines großen Konzerns tätig. Wir entwickeln Planungssoftware für Teilebedarfe der Produktion. Als ich mir die Architektur genauer anschaute, traute ich meinen Augen nicht. Die Schnittstelle zum Rich-Client, die der Server bereitstellt, besteht aus 6 Methoden:
- List<Object> getAll(Class class)
- List<Object> getAllByName(Class class, String name)
- List<Object> getAllByIds(Class class, UUID id1, ...)
- List<Object> getAllByUser(Class class)
- Object getById(Class class, UUID id)
- saveOrUpdate(Object o)
Grundsätzlich gefallen mir die generischen Methoden zum Laden relativ gut, auch wenn sie ein wenig Granularität vermissen. Aber was aus meiner Sicht absolut fragwürdig ist, ist die Methode saveOrUpdate. Nochmals zur Erinnerung: Diese Methode befindet sich auf dem Rich-Client. Einen weiteren Kick bekommt dieses Design, wenn man sich die Delegationen dieser Methode genauer anschaut. Im Grunde wird über alle Schichten bis zu der Hibernate-Persistenz delegiert, welche schlussendlich ein saveOrUpdate durchführt. Die technologischen Schichten sehen wiefolgt aus:
- Rich-Client angebunden mit Spring-Remoting
- Tomcat-Server, natürlich mit Spring konfiguriert
- Hibernate
- Oracle-DB
Da auf dem Appl-Server nur generische Elemente existieren, ist die Business-Logik komplett im Client. Die "Fachklassen" sind Beans ohne Logik, mal davon abgesehen, dass es Hibernate-gemappte Objekte sind, die durch die Weltgeschichte gereicht werden.
Nach erbitterten Diskussionen, kamen einige inhaltliche Zugeständnisse, die aber den generellen Ansatz verteidigen und vor allem zu sehr seltsamen Implementationen führen.
- Validierung findet klassenbezogen auf dem Server statt.
- Alle Anfragen an den Server werden im Moment über "synchronized" an der Methode "saveOrUpdate" synchronisiert.
- Es kamen von anderer Seite Ideen auf, alle ändernden Operationen an den Fach-Beans (set, add) mit Locking-Informationen anzureichern, damit man das synchronized nicht mehr benötigt.
Eine weitere Sache ist, dass konzeptionell Lost-Updates nur in besonderen Situationen abgefangen werden sollen. Eine generelle Vorgehensweise gibt es nicht.
Im letzten Monat wurde ein Modul entwickelt, welches auf der Seite des Clients Transaktionen suggeriert. Es gibt eine sogenannte Kontext-Klasse, über die Objekte angefordert angefordert werden können. Die Original-Beans werden gekapselt und mit einem Dirty-Mechanismus dekoriert. Schlussendlich wird auch hier eine Methode mit dem Namen "saveOrUpdate" aufgerufen, die nicht nur ein einziges Objekt überträgt, sondern alle neu erzeugten und geänderten und für jedes einzelne Objekt ein Hibernate-saveOrUpdate aufruft. Seitdem sind alle DB-Constraints Defferable und werden bei Einleitung der Transaktion Deffered, weil man die Reihenfolge der Objekte nicht sicherstellen kann ...
Lange Einleitung, kurze Frage: Macht man das heute so???
Freue mich über jeden Beitrag.