Designfrage...

[alley_catde]

Hallo zusammen,

ich beschäftige mich nun seit ca. 2-3 Wochen mit dem Thema EJB 3.0. Allerdings interessieren mich darüber hinaus einige Stilkonzepte für guten Code. Dazu ein kurzer Gedankenabriss:

Angenommen, ich möchte eine Benutzerverwaltung bauen. Ich habe meine Entities modelliert und dazu ein Remote-Interface + Bean-Implementierung. Allgemein kann eine Entity erzeugt, verändert und gelöscht werden. Sind dies dann schon die zu implementierenden Methoden und nutzt eine vorgeschaltete Managerklasse für komplexere Logik oder geht man in der Regel einen Schritt weiter und implementiert die Managerklasse direkt in die Bean. (Managerklasse bedeutet für mich eine komplette Implementierung der Fachlichkeiten)

Des weiteren habe ich in den Tutorials unterschiedliche Vorgehensweisen hinsichtlich der Entities gesehen. Es gab Bean-Implementierungen, die eine persistierte Entity direkt an den Client geben, als auch die Variante, dass die persistierten Entities niemals an den Client gegeben werden, sondern nur Teile davon verpackt in einer Art Detailklasse. Was ist denn hier die sauberste Vorgehensweise?

[Christian Marquardt]

M.E. sollte man die Schichten mindestens nach GUI - Geschäftlogik - Persistenz trennen

[alley_catde]

Das Prinzip ist mir schon bekannt. Mir geht's konkret um die Geschäftslogikschicht. Wie geht ihr vor?

[Empty]

Angenommen, ich möchte eine Benutzerverwaltung bauen. Ich habe meine Entities modelliert und dazu ein Remote-Interface + Bean-Implementierung. Allgemein kann eine Entity erzeugt, verändert und gelöscht werden. Sind dies dann schon die zu implementierenden Methoden und nutzt eine vorgeschaltete Managerklasse für komplexere Logik oder geht man in der Regel einen Schritt weiter und implementiert die Managerklasse direkt in die Bean. (Managerklasse bedeutet für mich eine komplette Implementierung der Fachlichkeiten)

Des weiteren habe ich in den Tutorials unterschiedliche Vorgehensweisen hinsichtlich der Entities gesehen. Es gab Bean-Implementierungen, die eine persistierte Entity direkt an den Client geben, als auch die Variante, dass die persistierten Entities niemals an den Client gegeben werden, sondern nur Teile davon verpackt in einer Art Detailklasse. Was ist denn hier die sauberste Vorgehensweise?

Meine Meinung dazu:

1. Niemals direkt die Entity Klassen an den Benutzer weitergeben. Generell kann es sein, dass du für ein und die selbe Entity unterschiedliche Sichtweisen haben willst (z.B. interessiert dich einmal nur der Benutzername und die Mailadresse und einmal Benutzername und Alter). In diesem Fall würdest du alle anderen Daten unnütz übertragen und so zuviel preisgeben und auch zuviel übertragen (was vor allem bei mobilen Geschichten relevant sein kann). Ein gängiges Konzept dafür wären DTOs (Data Transfer Objects). Das sind in der Regel einfache POJOs (Plain Old Java Objects), wo du nur die Properties eingibst, die von der Entity auch wirklich für den jeweiligen Anwendungsfall wichtig sind. In der Entity selbst, kannst du dann Methoden implementieren, um automatisch aus der jeweiligen Entity unterschiedliche DTOs zu formen. Beispiel:

Entity User(Username, Hashed Passwort, Alter, Mailadresse) inkl. 2 Methoden: getUserMailDTO und getUserAlterDTO, die dann den entsprechenden Typ zurückliefern

DTO UserMail(Username, Mailadresse)
DTO UserAlter(Username, Alter)

2. So nun zum Remote-Interface: Aus Erfahrung würde ich dir raten die oberste Ebene so abstrakt wie nur möglich zu halten - am besten ohne konkreter Implementierung. Deshalb würde ich dir ein einfaches Front- und Backendsystem vorschlagen. Heißt konkret: Du implementierst dir dein Backend, das im Hintergrund mit den Daten hantiert und z.B. irgendwelche Entity-Klassen persistiert, oder löscht etc. Dein Frontend ist quasi die Schnittstelle zum Benutzer. Der Vorteil ist hier, dass du dich nicht wirklich auf eine konkrete Implementierung festlegen musst - d.h. du könntest auch zwei unterschiedliche Schnittstellen entwickeln, mit denen eine Benutzerverwaltung ansprechbar ist, und im Hintergrund aber immer das gleiche Backend verwenden. Dadurch sparst du dir natürlich in Zukunft (bei möglichen Änderungen im Backend) alles doppelt zu machen. In beiden Fällen würde ich dir raten, nicht an den Interfaces zu sparen (auch hier wieder aus Gründen der Erweiterbarkeit).

Lg

[Christian Marquardt]

Der Thread ist 3 Jahre alt und muss nicht ausgebuddelt werden

[Empty]

Stimmt, ist mir leider zu spät aufgefallen