Hallo brian,
einige der Fragen beantworten sich einfach dadurch, dass das Diagramm ein bischen Objekte und Beziehungen mit ER-Diagramm vermischt. Das ER-Diagramm ist einfach die Implementierung eines UMLs, das die Beziehungen zwischen den in der Applikation existierenden Objekte beschreibt. Beispiel: Ein Benutzer ist der Ersteller eines Artikels. Aus diesem Grund wird das Objekt User mit dem Objekt Article assoziiert. Eine Assoziation muss deshalb her, da ein Artikel ohne eine Person existieren können soll und ein Artikel nicht zwangsläufig einer Person (alleine) gehören muss. Um diese Zuordnungen aufzulösen ist auch etwas Erfahrung notwendig, da Assoziationen und Kompositionen komplett andere Auswirkungen auf das Verhalten der Applikationen haben.
Zitat:
|
1. die unterscheidung von "ass_group_article" und "ass_user_article" verbunden mit den pfeilen auf "cms_article" impliziert das es "cms_article" überlassen ist, welche rechte gelten, wenn überschneidungen vorhanden sind, oder?
|
Nein, das nicht. Konkret geht es hier darum, dass nur diejenigen Artikel angezeigt werden, auf die ein Benutzer, oder eine Gruppe auch rechte haben. Gleiches Konstrukt siehst du auch bei den Navigationsknoten.
Zitat:
|
2. wofür ist "ass_navinode_article"? ich sehe hier eindeutig eine modularität, ich könnte also "cms_article" durch beliebieges anderes, also beispielsweise einem kategorie modul, ersetzen. das heißt demnach auch ich könnte beides auf einer seite mischen. demnach wäre die navigation auf dem selben level wie "benutzer und rechte", also "global", d.h. immer einzubinden. was ich nicht verstehe, ist wie dieses mischen der modularität, die du eindeutig vorsiehst, funktioieren soll....und: warum ist sie nicht teil des blocks "navigation"?
|
ass_navinode_article definiert, welche Inhalte unter welchem Navigationsknoten angezeigt werden. Diese Zuordnung kann beliebig sein, sprich ich kann alle Inhalte unter allen Navigationsknoten veröffentlichen, auf die ich auch Rechte habe. Das ist sehr generisch, ja. Einen cms_Article kann man erst mal nicht durch ein anderes Objekt ersetzen, es sei denn, es erbt von cms_Article, da diese Beziehung (noch) nicht existiert. Grundsätzlich ist das aber auch kein Problem, denn Module kann man auf der Inhaltsebene einbinden. Möglich wäre dies durch das Einbinden spezieller Tags wie
[SchreibMirHierDasNewsModulHin]. Du hast jedoch Recht, man könnte auf der Ebene der navigationsknoten noch weiter Modularisieren, in dem man dem Navigationsknoten eine Art Typ (z.B. "Seitenvorlage") zuordnet, der jeweils eine andere Ausgabe auf Grund der unter dem Navigationsknoten befindlichen Inhalte ausgibt, oder z.B. einfach nur ein Modul einbindet. Auf der Ebene der Inhalte würde ich das persönlich nicht machen.
Zitat:
|
3. ich sehe die sprache immer nur als eigenschaft eines objects. in diesem schema allerdings sehe ich, das die klasse "cms_language" im mittelpunkt steht. wer ruft wen?
|
Mittelpunkt ist ja wohl optisch falsch, der liegt am linken Ende.
Ich gebe dir natürlich Recht, Sprache ist ein Attribut eines Objekts, jedoch muss das auf ER-Ebene nicht der Fall sein. Ich habe das deshalb ausgelagert, dass ich einerseits entsprechende Beziehungen zu diesem Objekt aufbauen kann und andererseits eine Sprache und deren Attribute nur einmal pflegen muss. Weiterhin hätte ich sonst an vielen Stellen Mehrfachdatenhaltung, was ich persönlich nicht mag. Hier gilt - wieder aus Erfahrung die Regel:
wenn du ein identisches Attribut über verschiedene Objekttypen verwendest, so lagere es in ein eigenes Objekt aus und binde es über eine Beziehung an. Wie du das nun im Domänen-Model deiner Anwendung
präsentierst, bleibt der Mapper-Schicht vorbehalten. Eine Möglichkeit kann sein, die Sprache als Attribut in
jedes Objekt zu speichern.
Alle Fragen beantwortet?