Multi-Tier mit JBoss und Tomcat: Trennung der Ebenen

[Grizzly]

Hi,

mal 'ne Frage zur Trennung der einzelnen Schichten bei Multi-Tier Anwendungen:
Wir werden hier in nächster Zeit einige Anwendungen in einer Multi-Tier Architektur entwickeln. Dabei werden wir JBoss und Tomcat einsetzen. Nun kam aber die Frage nach der sinnvollen Trennung der Präsentations-, der Business Logik- und der Datenschicht auf:

Sollen von der Applikation-Schicht nur die Informationen oder Id an den Tomcat durchgegeben werden? Denn rein theoretisch würden ja auch die Informationen an sich sowie die eine Id reichen (die Id wird benötigt, um nachher bspw. von dieser Id aus einer ComboBox wieder auf das Objekt zurückschließen zu können).

Oder sollen die Objekte bis zum Tomcat durchgereicht werden? Der Tomcat müsste sich dann um das Mapping kümmern und die Objekte im Speicher behalten.

Was sind Eure Erfahrungen bzw. wir habt Ihr das gelöst?

 

[meez]

1. Warum Jboss und Tomcat...Löst alles mit einem reinen J2EE Server, sprich JBOSS..
2. Hähh ID..Die Datentrennung erfolgt automatisch, wenn du EJB's einsetzt??

 

[Grizzly]

Wir werden für die Datenbank <-> Objekt Geschichte Hibernate einsetzen. Damit ist auch die Trennung zwischen Business Logic und Datenschicht schon mal garantiert.
In der Web-Oberfläche kann ich aber nicht mit ganzen Objekten hantieren. Das maximale wäre eine Id (bzw. die Id, die Hibernate jedem Objekt verpasst), die ich dann bspw. durch eine ComboBox im Formular wieder zurückbekomme. Und von dieser Id muss ich ja irgendwie wieder zum Objekt kommen, um mit diesem dann in der Business Logic in den EJBs weiterverarbeiten zu können.

 

[Guest]

Was spricht dagegen, die Primärschlüssel zu verwenden?
Selbstverständlich vorausgesetzt, es sind keine Primärschlüssel,
die aus sensiblen Daten bestehen.
Optimal wäre es die Datenbank direkt so zu modelieren, dass
die Primarykeys rein zur Identifizierung eines Datensatzes
gedacht sind. Also kein Bezug zum tatsächlichen Inhalt der
Tabellenzeile. z.B. ein Integer (auto-increment)

Am Beispiel einer Tabelle-Person wäre das:

  ID, Rest der Daten
   1, Person_1
   2, Person_2
1234, Person_3
  56, Person_4
  789, Person_5

In HTML dann

<select name="person" ...>
<option value="1">Name Vorname_1
<option value="2">Name Vorname_2
<option value="1234">Name Vorname_3
<option value="56">Name Vorname_4
<option value="789">Name Vorname_5
</select>

Es sind zwar "nichtssagende" Daten diese ID's, kosten aber nichts und
lassen sich einheitlich für alle Tabellen in der Persistenzschicht
verwenden.

 

[Grizzly]

@Gast: Genau das war ja eine der Lösungen, die ich versucht habe zu skizzieren. Hibernate - das in dem Fall die Persistenzschicht wäre - generiert selber eindeutige Id's (muss ja auch selber die Objekte wieder erkennen ).

Meine Frage war eigentlich eher, wie Ihr das in Euren Projekten bisher gelöst habt und was Eure Erfahrungen waren.

 

[Guest]

Ich würde sagen, dass Webseiten stark Usecase bezogen sind.
Eine Möglichkeit, die sich anbietet, ist die Verwendung "versteckter"
Formularfelder, anhand deren man das entsprechende Formular
erkennt.
z.B. <input type=hidden name="formid" value="frm002">

Serverseitig wird dann anhand dieser ID's eine Statemaschine
bedient, die den Aufruf an den entsprechenden FormHandler
weiterleitet.
Stichworte: Statemaschine, Workflow, PageFlow, Chain of responsibility, Delegation

Das eigentliche Servlet sollte strohdoof sein und lediglich eine Statemaschine mit
Daten bedienen bzw. Daten/Anweisungen von der Statemaschine empfangen.

Hoffe, es bringt Dich auf paar Ideen.

 

[Grizzly]

Werde mal Google um die Stichwörter bemühen. Aber soweit mal Danke.

 

[Guest]

Wieso kannst/darfst du denn in der Präsentationsschicht keine Objekte verwenden? Hibernate lädt Value Objects, einfache Datenobjekte aus der Datenbank. Die eignen sich bestens zur Übertragung zwischen den Schichten. In der Präsentationsschicht werden die Daten aus den Ojekten mit dem geeigneten Framework (JSP, Struts, JAXB/XSLT etc.) an Html-Forms gebunden. Der Benutzer kann Werte ändern, die Objekte werden zurückübertragen und mit Hibernate in der Datenbank aktualisiert. Funktioniert problemlos.