Spezialisierung wie implementieren

Im Entwickler-Forum können Implementierungsdetails sowie Alternativen der Umsetzung diskutiert werden. // Here, developers can discuss implementation details of features of their projects.
Antworten
Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Spezialisierung wie implementieren

Beitrag von Thalo » 02.07.2014, 17:01:47

Hi,

ich schreibe gerade eine Kontaktverwaltung wobei es verschiedene Kontakttypen gibt z.B. Kunde, Mitarbeiter, Interessent etc. Die verschiedenen Typen verfügen über unterschiedliche Attribute die mit dem Objekt komponiert sind. Wie implementiere ich nun am besten die Biz- und Pres-Komponenten ohne all zu große Redundanz?

Wenn ich für jeden Kontakttyp ein spezialisiertes Modell habe muss ich für jedes unterschiedliche Methoden implementieren die sich nur gering unterscheiden. Wie könnte ich das sauberer lösen?
Und wie implementiere ich die Pres-Komponenten, weil ich doch für jeden Kontakttyp unterschiedliche Formulare benötige, die zum Teil jedoch gleich sind.

Vielleicht hat ja von euch jemand eine Idee :)

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Spezialisierung wie implementieren

Beitrag von dr.e. » 06.07.2014, 00:04:27

Hi Thalo,

konkrete Typen würde ich definitiv auch konkret modellieren. Beispiel: UMGT-Modul, dort hast du auch UmgtUser und UmgtGroup.
Wenn ich für jeden Kontakttyp ein spezialisiertes Modell habe muss ich für jedes unterschiedliche Methoden implementieren die sich nur gering unterscheiden. Wie könnte ich das sauberer lösen?
Und wie implementiere ich die Pres-Komponenten, weil ich doch für jeden Kontakttyp unterschiedliche Formulare benötige, die zum Teil jedoch gleich sind.
Vertikale Vererbung kannst du per extends lösen, horizontale Vererbung via Traits.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Spezialisierung wie implementieren

Beitrag von Thalo » 06.07.2014, 17:07:51

Hallo Doc,
dr.e. hat geschrieben:Vertikale Vererbung kannst du per extends lösen, horizontale Vererbung via Traits.
Traits sind nicht ganz das was ich suche. Ich dachte eher daran ein konkretes Modell (z.B Kunde) in ein generisches (Kontakt, Attributes) zu übersetzen und damit zu arbeiten. Für die Pres evtl. wiederverwendbare Formulare oder so ähnlich.

Ich habe hier ein Diagramm wie ich mir die Datenmodellierung vorstelle um möglichst keine Redundanz zu haben:

das Problem ist, dass ich nun schon 8 Joins benötige um einen Kontakt auszulesen. Hast du evtl. eine bessere Idee wie ich das abbilden kann? Oder wäre es vielleicht sogar klüger hier mit redundanten Kontakten zu arbeiten und wenn ein Kontakt gleichzeitig Kunde und Mitarbeiter ist diesen redundant zu halten?

So wie es nun ist müsste z.B. ein Angebot das mit einem Kunden verknüpft wird mit der ContactDefinition verknüpft werden. Oder ist es besser statt alle Kontakte in einer ContactTable (Ansprechpartner, Kunde, Mitarbeiter etc.) eine Tabelle Ansprechpartner, Kunde, Mitarbeiter etc.?
Zuletzt geändert von Thalo am 13.07.2014, 18:30:47, insgesamt 1-mal geändert.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Spezialisierung wie implementieren

Beitrag von dr.e. » 07.07.2014, 21:45:14

Ich finde das Modell logisch. Sind vielleicht 8 Joins, andererseits ist es leicht erweiterbar, da du konkrete Typen definiert hast. Die Unterscheidung der Attribute und Vendor-Attribute könntest du vielleicht noch zusammenlegen und an einen Typen knüpfen.
Oder wäre es vielleicht sogar klüger hier mit redundanten Kontakten zu arbeiten und wenn ein Kontakt gleichzeitig Kunde und Mitarbeiter ist diesen redundant zu halten?
Nutze doch eine Klassifizierung, sprich hänge beide Attribute an die Instanz. Als Person kannst du ja auch - mehr oder weniger gleichzeitig - Fahrgast und Fahrer sein.
So wie es nun ist müsste z.B. ein Angebot das mit einem Kunden verknüpft wird mit der ContactDefinition verknüpft werden. Oder ist es besser statt alle Kontakte in einer ContactTable (Ansprechpartner, Kunde, Mitarbeiter etc.) eine Tabelle Ansprechpartner, Kunde, Mitarbeiter etc.?
Auch das ist möglich. Wenn deine Applikation nicht so stark auf Ausbau/Anpassung etc. ausgelegt ist, kannst du auch konkreter modellieren. Die Implementierung fällt dann vielleicht etwas leichter.

Mein Ansatz wäre mit dem o.g. Modell zu starten und wenn du siehst, dass es zu komplex/kompliziert wird und keine Anforderungen auf krasse Erweiterbarkeit bestehen, auf ein konkretes Modell zu gehen. Die Präsentation kannst du dann i.d.R. weiterverwenden.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Spezialisierung wie implementieren

Beitrag von Thalo » 08.07.2014, 20:47:18

Hi Doc,

gibt es eine Möglichkeit Teile eines Formulars in unterschiedlichen Templates wiederzuverwenden?
dr.e. hat geschrieben:Nutze doch eine Klassifizierung, sprich hänge beide Attribute an die Instanz. Als Person kannst du ja auch - mehr oder weniger gleichzeitig - Fahrgast und Fahrer sein.
Also doch nicht konkret modellieren?
dr.e. hat geschrieben:Auch das ist möglich. Wenn deine Applikation nicht so stark auf Ausbau/Anpassung etc. ausgelegt ist, kannst du auch konkreter modellieren.
Das Problem ist, ich weiß nicht wie ich in der Form "unkategorisierte" Kontakte selektieren soll. Ein Join auf alle Tabellen und prüfen ob NULL würde jedes mal eine Anpassung bedeuten sobald ein neuer Typ hinzukommt und eine zusätzlichen Typen-Tabelle könnte zu Inkonsistenz führen. Eine andere Möglichkeit fällt mir jedoch nicht ein.

Um den Mapper redundanzfrei zu halten habe ich das Pattern gefunden: http://ideababy.ru/0321127420_ch12lev1sec8.shtml einzige Problem ist, dass für jeden Kontakttyp ein eigener Kontakt angelegt werden muss.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Spezialisierung wie implementieren

Beitrag von dr.e. » 09.07.2014, 12:10:03

Hallo Thalo,
gibt es eine Möglichkeit Teile eines Formulars in unterschiedlichen Templates wiederzuverwenden?
Auf Basis des Templates (aktuelle) nein, wenn du das Formular im Controller an Hand von Markern aufbaust, kannst du die Funktionen per Vererbung oder Traits wiederverwenden.
Also doch nicht konkret modellieren?
An sich schon mit dem "ContactType", die Frage ist, ob das die Applikation auch so nutzt.
Das Problem ist, ich weiß nicht wie ich in der Form "unkategorisierte" Kontakte selektieren soll. Ein Join auf alle Tabellen und prüfen ob NULL würde jedes mal eine Anpassung bedeuten sobald ein neuer Typ hinzukommt und eine zusätzlichen Typen-Tabelle könnte zu Inkonsistenz führen. Eine andere Möglichkeit fällt mir jedoch nicht ein.
Un-kategorisierte Objekte darf es nicht geben, sonst brichst du das Datenmodell.
Um den Mapper redundanzfrei zu halten habe ich das Pattern gefunden: http://ideababy.ru/0321127420_ch12lev1sec8.shtml einzige Problem ist, dass für jeden Kontakttyp ein eigener Kontakt angelegt werden muss.
Das ist IMHO auch ok.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Spezialisierung wie implementieren

Beitrag von Thalo » 09.07.2014, 16:59:17

Hi Doc,
dr.e. hat geschrieben:Auf Basis des Templates (aktuelle) nein, wenn du das Formular im Controller an Hand von Markern aufbaust, kannst du die Funktionen per Vererbung oder Traits wiederverwenden.
hab in der Doku den core:appendnode-Tag gefunden. Ist der nicht genau das was ich meine?
dr.e. hat geschrieben:An sich schon mit dem "ContactType", die Frage ist, ob das die Applikation auch so nutzt.
Dann verstehe ich nicht was du meinst. Wie soll ich denn konkret und generisch modellieren? :?
dr.e. hat geschrieben:Un-kategorisierte Objekte darf es nicht geben, sonst brichst du das Datenmodell.
In wie fern das Datenmodell brechen? Würde ein Typ "Other" genügen oder muss es eine leere Attribute Tabelle geben wie z.B. bei Customer? Oder würdest du sogar eine Mischung aus beidem (leere, nur mit PK)Tabelle + für das Mapping einen Typ?

Und wie sollte man mit Daten umgehen die nur einen bestimmten Kontakttypen zugeordnet sein dürfen? z.B. nur einem privaten Kontakt?

Was hältst du eigentlich von dem http://martinfowler.com/eaaCatalog/conc ... tance.html Pattern?

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Spezialisierung wie implementieren

Beitrag von Thalo » 15.07.2014, 19:23:51

Hallo Doc,

mein Problem war, dass ich das als eine "is-a" Beziehung gesehen habe anstatt als eine Rolle. Das ist bestimmt auch das worauf du hinaus wolltest? :)

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Spezialisierung wie implementieren

Beitrag von dr.e. » 15.07.2014, 22:06:36

Das Bild von einer Rolle passt gut, ja! :)
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Spezialisierung wie implementieren

Beitrag von Thalo » 15.07.2014, 22:22:11

Hi Doc,

gibt es eine Möglichkeit einen DataMapper zu implementieren ohne eine Bezieungs-Entität (z.B. Guestbook und Comments) einzeln zu laden? Wäre sowas z.B.:

Code: Alles auswählen

function loadGuestbookWithComments($entry) {
//load entry
//select ... inner join comments ... where entry = $entry
while() {
$comments[] = $this->map2DomainObject($sql->fetchData($result));
}
bereits schlechtes Design? Oder ist das schon eine Verletzung des SRP?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Spezialisierung wie implementieren

Beitrag von dr.e. » 16.07.2014, 09:14:18

Hallo Thalo,
gibt es eine Möglichkeit einen DataMapper zu implementieren ohne eine Bezieungs-Entität (z.B. Guestbook und Comments) einzeln zu laden?
Natürlich kannst du das tun. Hierbei kannst du das Laden entweder explizit in einem Mapper ausformulieren oder auf Domänen-Objekte setzen, die das Laden intern verstecken. Mit dem GORM könntest du letzteres recht einfach implementieren, in dem du dem konkreten DO z.B. eine Methode getComments() gibst und intern die Logik des Nachladens versteckst. Das Hinzufügen geht dann analog.
Wäre sowas z.B.: [..] bereits schlechtes Design? Oder ist das schon eine Verletzung des SRP?
Meiner Meinung nach ist das absolut zulässig. Der Mapper kümmerst sich an dieser Stelle lediglich um das Laden von Entitäten. Es geht beim Single Responsibility Principle auch weniger darum, dass eine Methode nur eine Zeile Code (Extremfall!) enthalten darf um dieses zu erfüllen, sondern mehr darum, dass nur gleichartige Aufgaben erledigt werden. Brauche ich in meinem Entitäten-Modell zwei Objekte für einen Bereich, so ist es meiner Meinung nach absolut legal dies in eine Methode zu verpacken.
Viele Grüße,
Christian

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast