Welches Design Pattern ist geegneit.

[perlenfischer1984]

HAllo ich bins mal wieder.

Folgende Situatio möchte ich abbilden. ICh möchte für einen Sportler, der in verschiedenen MAnnschaften eingesetzt werden kann, eine Terminübersicht herausgeben.
Nun meine Überlegung.

GAnz oben steht der Sportverein. Dieser hat eine Mitgliederliste. Innerhalb des Vereins gibt es verschiedene TEams. Jedes Team hat auch eine TEamliste. Außerdem gibt es verschieden Wettbewerbe. Jeder Wettbewerb beinhaltet verschiedene Spiele. Jedes Spiel besteht aus einem Heim - und einer Gastteam

Nun hat jeder WEttberwerb verschieden Anfordungen. Z.b Muss min ein lizenzierter Trainer vorhanden sein. WEnn ich nun ein Mitglied (auch einen Trainer) zu einem Team hinzuführe, so möchte ich, dass der entsprechenende Wettbewerb validiert wird. Das bedeutet, dass geprüft wird, ob alle teilnehmenden TEam die Vorraussetzungen erfüllen.

Nun mein Frage, welches Design Pattern würde man für so einen Sachverhalt nutzen. Mein Vorschlag wäre mit einem Observer Patter zu versuchen

Was meint ihr dazu.

 

[Meeresgott]

Würde ich anders angehen. Ich würde es wie in einer Datenbank machen und deine Objekte 'unabhängiger' voneinander machen. Klingt für mich so als würdest du einen Haufen Informationen verwalten wollen und das können Datenbanken besser.

Du hast eine Mannschaft-Liste eine Spieler-Liste eine Wettbewerb-Liste usw. und dann hast du Relationstabellen die sagen Spieler x ist in Mannschaft y und Mannschaft y hat an Wettbewerb z Teilgenommen (Das wäre es zur Speicherung und Verwaltung) beim Datenbank INSERT kannst dann prüfen, ob die Regeln eingehalten wurden oder nicht.

So zu den Objekten. Diese werden gefüllt, wenn Sie gebraucht werden. Du brauchst alle Wettbewerbe? holst du dir von der Datenbank.
Wenn man es jetzt so machen würde wie du, dann würdest mit diesem Aufruf restlos alle Daten in den Heap holen. Bei jeden Wettbewerb ist jede Mannschaft (fast) vertreten in allen Mannschaften sind (logisch) insgesamt alle Spieler die alle ihre Terminkalender haben usw. Ich würde schauen, dass ich Anzeige Objekte schreiben würde, denen es 'egal' ist was Sie anzeigen und mir auch nur die Informationen von der DB hole die ich angezeigt haben möchte.

Falls das für deine Implementierung überhaupt nicht in Frage kommt kannst du sowas wie das Iterator-Pattern verwenden da hättest du alle Objekte im Heap und könntest Sie leicht durchstöbern.

Aber in beiden Fällen, würde ich POJOs nehmen (gut beim Iterator Pattern logischerweise Iterator implementieren) Aber sonst keine Abhängigkeiten von vererblicher Art.
Da ich die Objekte wie Daten-Objekte behandeln würde (Was sie in meinen Augen auch sind)

Hoffe ich konnte dir ein wenig helfen

 

[mrBrown]

Nun mein Frage, welches Design Pattern würde man für so einen Sachverhalt nutzen. Mein Vorschlag wäre mit einem Observer Patter zu versuchen

Wieso denkst du da an Observerpattern? Umsetzten lässt sich das damit - ich würde es aber nicht dafür benutzen.

Ich würde eher was DDD-ähnliches Nutzen.
Die Methode zum hinzufügen eines Trainer wird in einen Service ausgelagert, und der kann dann alles entsprechende prüfen.
Zusätzlich beim Hinzufügen zu einem Wettbewerb kann der Wettbewerb selbst prüfen, ob alle Teams den Anforderungen entsprechen.

Ansonsten kann auch das Team den Wettbewerb kennen, an dem es teilnimmt - wird für das Team ein neuer Trainer eingesetzt, prüft das Team vorher für den Wettbewerb, ob es zulässig ist.

Klingt für mich so als würdest du einen Haufen Informationen verwalten wollen und das können Datenbanken besser.

DB sollte nur speichern - nicht Hauptteil der Anwendung sein

Du hast eine Mannschaft-Liste eine Spieler-Liste eine Wettbewerb-Liste usw. und dann hast du Relationstabellen die sagen Spieler x ist in Mannschaft y und Mannschaft y hat an Wettbewerb z Teilgenommen (Das wäre es zur Speicherung und Verwaltung) beim Datenbank INSERT kannst dann prüfen, ob die Regeln eingehalten wurden oder nicht.

Ich würde die validieren nicht auf DB-Ebene machen, sowas gehört immer zur Anwendungslogik - auf DB-Ebene sollte man das nur zusätzlich machen.

Da ich die Objekte wie Daten-Objekte behandeln würde (Was sie in meinen Augen auch sind)

Den Punkt würde ich genau anders sehen - Die Objekte sind die relevanten Teile der Anwendung, nicht nur Datenhalter

 

[Meeresgott]

Da merkt man mal wie die Meinungen auseinander gehen können

Aber du hast schon Recht es ist Anwendungslogik, wenn ich recht drüber Nachdenke. Hab mich die letzten Tage wohl zu sehr mit DB's befasst aber man könnte...

 

[mrBrown]

Da merkt man mal wie die Meinungen auseinander gehen können

Aber du hast schon Recht es ist Anwendungslogik, wenn ich recht drüber Nachdenke. Hab mich die letzten Tage wohl zu sehr mit DB's befasst aber man könnte...

Kommt drauf an, welchen Weg man als erstes kennen und lieben gelernt hat - manche mögen halt lieber die dunkle Seite ;P

Für die einen ist die DB das wichtigste, für die anderen nur ne nervige externe Abhängigkeit - welches ich besser finde dürfte klar sein

 

[Meeresgott]

Für die einen ist die DB das wichtigste, für die anderen nur ne nervige externe Abhängigkeit - welches ich besser finde dürfte klar sein

Ganz klar die DB!

 

[Meniskusschaden]

DB sollte nur speichern - nicht Hauptteil der Anwendung sein

Es gibt aber auch Anwendungen, die die gesamte Geschäftslogik mit DB-Prozeduren realisieren. Ein Beispiel ist AvERP. Das kann durchaus Vorteile haben und gut funktionieren.

 

[mrBrown]

Es gibt aber auch Anwendungen, die die gesamte Geschäftslogik mit DB-Prozeduren realisieren. Ein Beispiel ist AvERP. Das kann durchaus Vorteile haben und gut funktionieren.

Ausnahmen bestätigen natürlich immer die Regel