patterns:role
Differences
This shows you the differences between two versions of the page.
|
patterns:role [2013/01/04 14:37] rtavassoli |
patterns:role [2013/01/04 15:21] (current) rtavassoli |
||
|---|---|---|---|
| Line 72: | Line 72: | ||
| \\ \\ | \\ \\ | ||
| Zugegeben, das ist keine so starke Beziehung wie eine tatsächliche Rolle, und mann kann nicht über Employee.Person die Person erhalten. In [[technology:domainmodel:|DDD]] ist aber ein wichtiger Aspekt die sinnvolle Aufteilung von Objekten in bestimmte Aufgabenbereiche, um die einzelnen Bereiche überschaubar zu halten. Wenn man nun weiß, dass der Mitarbeiter eine Rolle einer Person darstellt, kann man die Mitarbeiter-ID verwenden, um Methodenaufrufe direkt an die Person zu senden. Somit ist die //geteilte Identität// als explizite Definition einer Objekt-Rollenbeziehung eine flexible und starke Beziehung, die das Rollenmuster sinnvoll wiedergibt. | Zugegeben, das ist keine so starke Beziehung wie eine tatsächliche Rolle, und mann kann nicht über Employee.Person die Person erhalten. In [[technology:domainmodel:|DDD]] ist aber ein wichtiger Aspekt die sinnvolle Aufteilung von Objekten in bestimmte Aufgabenbereiche, um die einzelnen Bereiche überschaubar zu halten. Wenn man nun weiß, dass der Mitarbeiter eine Rolle einer Person darstellt, kann man die Mitarbeiter-ID verwenden, um Methodenaufrufe direkt an die Person zu senden. Somit ist die //geteilte Identität// als explizite Definition einer Objekt-Rollenbeziehung eine flexible und starke Beziehung, die das Rollenmuster sinnvoll wiedergibt. | ||
| + | \\ \\ | ||
| + | Ein weiterer Punkt ist der, dass ein Mitarbeiter ohne eine Person wenig Sinn ergibt. Bei einer echten Rollenbeziehung mit dem Mitarbeiter als Rolle einer Person ist die korrekte Beziehung sichergestellt. Bei der losen Beziehung nicht. Die Applikationsschicht muss an dieser Stelle die Beziehung sicher stellen. Wenn sie einen Befehl erhält, einen Mitarbeiter anzulegen, muss sie erst prüfen, ob es die Person bereits gibt. Erst dann legt sie den Mitarbeiter an, ansonsten wirft sie einen Fehler. | ||
| + | \\ \\ | ||
| + | Es gibt sicherlich Wege und Methoden, eine stärkere Beziehung herzustellen, die auch in der Domäne verankert ist und nicht in der Applikationsschicht. Der Konstruktor eines Mitarbeiters könnte z.B. eine Person verlangen. So wird die Applikationsschicht dazu gezwungen, die Person vorher zu laden. Dafür müssen die beiden Domänen aber auch einen gemeinsamen Prozessraum haben, was nicht immer der Fall sein muss. | ||
| + | \\ \\ | ||
| + | Man darf aber nicht vergessen, dass alle Modelle nur Abstraktionen sind. Zudem ist die Applikationsschicht nicht unwichtiger als die Domänenschicht. Sie nimmt die Bausteine der Domänen und macht daraus eine Anwendung. Objekte und deren Rollen zusammen zu führen, z.B. über Prüfungen, ob ein Objekt für eine Rolle überhaupt vorhanden ist, kann durchaus eine Aufgabe der Applikationsschicht sein. | ||
patterns/role.1357306646.txt.gz · Last modified: 2013/01/04 14:37 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
