Zyklische Abhängigkeiten

Question

Betrachten Sie eine normale Anwendung für Kundenaufträge basierend auf dem MVC-Muster mit WinForms. Der Ansichtsteil ist zu groß geworden (über 4000 Dateien) und muss in kleinere geteilt werden.

---

Für dieses Beispiel werden wir drei Projekte für die Ansicht Teil verwenden:

• Haupt - hat Abhängigkeiten zu den anderen 2 Projekte. Instanziiert die Formulare mit den Listen.
• Kunden - hat 2 Formulare - Kundenliste und Kundendetails.
• Orders - hat 2 Formulare - Bestellliste und Bestelldetails.

---

Auf den Kundendaten bilden dort für diese Kunden auch eine Liste der Aufträge ist. Die Liste wird vom OrdersController empfangen, so dass es kein Problem ist, sie zu bekommen. Wenn der Benutzer eine Bestellung auswählt, erhält die Liste ihre Guid und gibt sie als Referenz an das Bestelldetails-Formular weiter.

Dies würde bedeuten, dass wir einen Verweis auf Orders Project im Kundenprojekt benötigen.(1)

Aber auch auf der Bestellung Details Formular gibt es einen Link zu dem Kunden, der diese Bestellung gemacht hat. Wenn Sie darauf klicken, sollte das Formular "Kundendaten" geöffnet werden.

Dies würde bedeuten, dass wir einen Verweis auf Kundenprojekt im Auftragsprojekt benötigen.(2)

Aus (1) und (2) werden wir zyklische Abhängigkeiten zwischen den Bestellungen und Kunden-Projekte haben.

---

Wie kann das vermieden werden? Eine Art von Plug-in-Architektur? Das Projekt ist bereits entwickelt und die beste Lösung wäre so wenig Code wie möglich.

Answer 1

Ändern Sie mindestens einen der Typen in eine Schnittstelle.

Zum Beispiel eine ICustomer-Schnittstelle und einen Kundentyp, der diese Schnittstelle implementiert. Fügen Sie nun den ICustomer zum Projekt Aufträge hinzu, und legen Sie aus dem Kundenprojekt einen Verweis auf das Projekt Bestellungen fest, damit Sie die Schnittstelle implementieren können. Der Auftragstyp kann jetzt gegen den ICustyp arbeiten, ohne die tatsächliche Implementierung zu kennen.

Und für eine bessere Lösung :-) Erstellen Sie sowohl eine ICustomer- als auch eine IOrder-Schnittstelle und fügen Sie sie einem dritten Bibliotheksprojekt hinzu.Und referenzieren Sie dieses Projekt von den anderen beiden und arbeiten Sie nur mit den Schnittstellen, niemals mit der Implementierung.

Answer 2

Wenn sie so eng gekoppelt sind, sollten sie vielleicht nicht geteilt werden.

Answer 3

Schnittstellen extrahieren und in separate Baugruppe stecken. Da Sie MVC-Architektur verwenden, sollte es nicht schwer sein. Sehen Sie sich den Microsoft Composite UI-Anwendungsblock für Beispiele und bewährte Vorgehensweisen an.

Answer 4

Ich denke, dass Ihr Hauptproblem nicht die Architektur Ihrer Anwendung ist. Sie müssen die Grenzen verstehen und die Funktionalität unter ihnen aufteilen. Die Abteilung wie die Ihre ist ziemlich künstlich, Sie versuchen, die Anwendung basierend auf den Domänenobjekten zu teilen. Versuchen Sie es mit Benutzerrollen oder funktionalen Themen, und das Problem könnte verschwinden.

Aus technischer Sicht verstehe ich nicht, warum Ihre Ansichten sich gegenseitig kennen sollten - das klingt ein bisschen komisch. Sie werden Ihre Daten und Ihre Geschäftslogik nicht aufteilen, und am Ende des Tages ist eine GUID nur ein Stich, den Sie mit anderen Methoden leicht weitergeben könnten.