2015-10-13 10 views
16

Ich versuche ein Live-Benachrichtigungssystem zu implementieren (wie fb, xing, twitter ..). Daher habe ich vor dem Erstellen der Entitäten ein UML-Klassendiagramm erstellt. Die Vitrine ist die folgende:Live Benachrichtigungen UML Klassendiagramm


EDIT: Ich dachte, diesen Ansatz, und es scheint, als ob dies nicht der richtige ist. Lassen Sie uns das folgende Szenario überprüfen: Benutzer U fügt in Bild E von Event E einen Kommentar C hinzu. Wie man das richtig speichert, ich meine, EventNotification hat nur einen Verweis auf das Ereignis E, aber nicht auf I und C. Daher müsste ich ein erstellen "EventImageNotification" Klasse auch und das wäre ein Durcheinander. Wäre es eine bessere Lösung, nur eine "Notification" -Klasse zu haben und ein "Metadaten" -Feld hinzuzufügen, das Verweise auf alle beteiligten Felder speichert?


(Ich verwende eine OR-Mapper Beziehungen später zu implementieren).

[1] Ein Benutzer kann Ereignisse erstellen, z. "Silvesterparty 2015". (OneToMany). Dieses Ereignis verfügt über ein Dashboard, auf dem Benutzer Updates abonnieren können, wenn der Ersteller etwas zu diesem Ereignis (ManyToMany) veröffentlicht.

[2] Wenn ein Benutzer etwas im Dashboard der Veranstaltung veröffentlicht, sollten abonnierte Benutzer eine Benachrichtigung erhalten. Daher habe ich die EventNotification-Klasse erstellt. Beziehung zwischen Benutzer und EventNotification ist ManyToMany.

[3] Um es sauber zu halten, habe ich eine AbstractNotification-Klasse erstellt, die sich auf einen Benachrichtigungstyp bezieht. Ein Benachrichtigungstyp ist etwas wie name = "EventPost" und template = "Benutzer Benutzer hat etwas neues auf Ereignis __event gepostet".

[4] Die abstrakte Klasse NotificationConnector enthält Felder für die Mapping-Klasse zwischen EventNotification und User (UserEventNotification). Ich habe sie erstellt, um sie in der Zukunft leicht zu erweitern, z. Ein Benutzer kann Bücher erstellen, die auch Ereignisse usw. auslösen. Dann müsste ich eine "BookNotification" - und eine "UserBookNotification" -Klasse erstellen, um Benachrichtigungen für diese neue Entität zu speichern.

Ist dieser Ansatz ein guter oder völlig durcheinander? Bitte sagen Sie mir Ihre Ideen zu diesem Diagramm:

(Die Pfeile zum Erstellen von Verknüpfungen sollten normale Linien gewesen sein, das Werkzeug, das ich verwendet habe, konnte das einfach nicht tun).

Notification UML

+0

Update: Ich verwende jetzt ein Metadatenfeld in Kombination mit einem NotificationType und es funktioniert für alle Arten von geschachtelten Benachrichtigungen. – user3746259

Antwort

0

Nur ein paar Beobachtungen:

  • Die beiden abstrakten Klassen scheinen überflüssig zu sein, da man sie in einem Kontext nur verwenden.
  • Die has Verbindung von User sollte zu UserEndNotification statt der abstrakten Klasse gehen (die ich sowieso empfehlen zu fallen).
  • würde ich NotificationType ein <<enumeration>>
  • eher machen als eine owns Beziehung mit würde ich eine isOwner und isSubscriber Eigenschaft eine Assoziationsklasse zwischen User und Event und fügen Sie verwenden.
+0

Hallo Thomas, danke für deine Gedanken. Ich werde deine Punkte kommentieren. [1] Ich habe die abstrakten Klassen erstellt, weil es in Zukunft mehr Entitäten geben wird, die mit den abstrahierten Klassen verbunden werden. [2] Das klingt logischer! [3] Lies das auch, aber dann wäre es schwerer, die Namen & Platten über einen Admin-Bereich zu verwalten? [4] das klingt ziemlich gut, ich dachte auch darüber nach, wusste aber nicht, was der empfohlene/leistungsfähigere Weg wäre. Normalerweise können Sie mehrere separate Beziehungen zwischen zwei Klassen haben, aber ich denke, beide Ansätze sollten funktionieren. – user3746259

+0

3) Hängt davon ab. Es gibt Vor- und Nachteile. Nur ein Gedanke. 4) Erzähl nicht über die Leistung. Dies bleibt der Implementierung überlassen. Ihre m-n-Beziehung ist bereits eine Assoziationsklasse (obwohl eine einfache), die Sie wahrscheinlich über eine Tabelle mit zwei Fremdschlüsseln abbilden würden. –

Verwandte Themen