zyklische Abhängigkeiten

Question

Betrachten wir einen normalen Kunden-Aufträge Anwendung basierend auf Muster MVC WinForms. Der Blick Teil hat zu viel gewachsen (über 4000 Dateien) und es muss in kleinere aufgeteilt werden.

---

In diesem 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 aus.
• Kunden - hat zwei Formen -. Kundenliste und Kundendaten
• Aufträge - hat zwei Formen -. Auftragsliste und Bestelldaten

---

Auf den Kundendaten bilden gibt es auch eine Liste der Aufträge für diese Kunden. Die Liste wird von dem Orders erhalten, so dass es kein Problem ist es zu bekommen. Wenn der Benutzer einen Auftrag auswählt, wird die Liste bekommt es guid und gibt es als Verweis auf das Formular Bestelldetails.

Dies würde bedeuten, dass wir einen Verweis auf Aufträge Projekt in dem Kunden-Projekt haben müssen. (1)

Aber auch auf den Auftragsdaten bildet es eine Verbindung zu den Kunden, die diesen im Auftrag hergestellt. Wenn Sie darauf klicken, sollte es die Kundendaten Formular öffnen.

Dies würde bedeuten, dass wir einen Verweis auf Kunden-Projekt in dem Orders Projekt haben müssen. (2)

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

---

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

Answer 1

Ändern mindestens einer der Typen an eine Schnittstelle.

Zum Beispiel hat eine ICustomer Schnittstelle und einen Kundentyp, der diese Schnittstelle implementiert. Jetzt die ICustomer zum Auftrag Projekt hinzufügen und von den Kunden einen Verweis auf die Aufträge Projekt eingestellte Projekt, so dass Sie die Schnittstelle implementieren können. Der Typ Order kann nun arbeiten gegen die ICustomer Art, ohne die tatsächliche Implementierung zu kennen.

Und für eine bessere Lösung :-) Erstellen Sie sowohl eine ICustomer und eine iOrder Schnittstelle und fügen Sie sie zu einem dritten Bibliotheksprojekt. Und dieses Projekt von den beiden anderen verweisen und nur mit den Schnittstellen arbeiten, nie mit dem Implemenation.

Answer 2

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

Answer 3

Extract Schnittstellen und sie in separaten Assembly setzen. Da Sie MVC-Architektur verwenden, sollte es nicht schwer sein. Werfen Sie einen Blick auf Microsoft Composite-UI Anwendungen Block für Beispiele und gute Praktiken.

Answer 4

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

Aus technischer Sicht Ich verstehe nicht, warum Sie Ihre Ansichten bewusst voneinander Existenz sein sollte - die ein wenig seltsam für mich klingt. Sie werden auf Ihre Daten und Ihre Geschäftslogik und am Ende des Tages nicht geteilt eine GUID ist nur ein Stachel Sie leicht über mit verschiedenen Methoden übergeben könnten.