2010-04-07 3 views
11

Unser aktuelles Projekt ist in ein zirkuläres Abhängigkeitsproblem geraten. Unsere Geschäftslogik-Assembly verwendet Klassen und statische Methoden aus unserer SharedLibrary-Assembly. Die SharedLibrary enthält eine ganze Reihe von Hilfsfunktionen, z. B. eine SQL Reader-Klasse, Enumeratoren, globale Variablen, Fehlerbehandlung, Protokollierung und Validierung.Circular Dependency Solution

Die SharedLibrary benötigt Zugriff auf die Business-Objekte, die Business-Objekte benötigen jedoch Zugriff auf SharedLibrary. Die alten Entwickler lösten diesen offensichtlichen Codegeruch, indem sie die Funktionalität der Geschäftsobjekte in der gemeinsam genutzten Bibliothek replizierten (sehr anti-DRY). Ich habe einen Tag damit verbracht, über meine Optionen zu lesen, um das Problem zu lösen, aber ich bin am Ende.

Ich bin offen für die Idee der Architektur Redesign, aber nur als letztes Mittel. Wie kann ich eine Shared-Helper-Bibliothek haben, die auf die Business-Objekte zugreifen kann, während die Business-Objekte weiterhin auf die Shared-Helper-Bibliothek zugreifen?

+2

Die offensichtliche Frage ist: Warum benötigt die gemeinsame Bibliothek Zugriff auf die Business Objects? Wenn Sie das beantworten können, haben Sie eine Lösung. – Aaronaught

+0

Die SharedLibrary enthält eine abstrakte globale Variablenklasse mit statischen Eigenschaften. Diese Eigenschaften werden von Werten aus der Datenbank erzeugt, daher die Notwendigkeit von Geschäftsobjekten, dies ist nur ein Beispiel von vielen. Und natürlich benötigen die Business-Objekte Zugriff auf diese Konstanten. – gfoley

+2

Deshalb verwende ich niemals vage Begriffe wie "shared", um eine Bibliothek zu beschreiben. Was macht es eigentlich? Was Sie eine gemeinsame Bibliothek nennen, hat eindeutig viel zu viele Verantwortlichkeiten, und vielleicht auch die Business-Objekt-Bibliothek. In der Regel werden diese Lösungen gelöst, indem die wirklich unabhängigen Klassen/Schnittstellen in ihre eigene Bibliothek gestellt werden. – Aaronaught

Antwort

17

Sie könnten ein separates Projekt nur für Wertobjekte (keine Logik) und Schnittstellen erstellen.

Lassen Sie Ihre Shared Library-Klassen implementieren die Schnittstellen, und die Business-Bibliothek hängt von den Schnittstellen ab (höre ich mehr testbaren und entkoppelten Code hier? Nicht zu erwähnen, dass Sie die Abhängigkeit von der freigegebenen Bibliothek entfernen).

Im Idealfall könnten Sie die Geschäftsobjekte, auf denen Ihre gemeinsam genutzte Bibliothek basiert, auch von diesem zusätzlichen Projekt abhängig machen. Wenn die Geschäftsobjekte zu komplex sind, können Sie sie auch in Schnittstellen umwandeln.

Sie werden beide Projekte haben nicht aufeinander abhängig, sondern nur auf einem anderen Projekt mit nur „Dummy“ Objekte (keine Logik):

Geschäft ---> Schnittstellen und Wertobjekte < --- Shared Library

Jetzt sind die entkoppelt =)

+0

Dies ist die Antwort. – Strelok

+0

Wenn Sie so weit gehen, um die Abhängigkeit wegzubauen, warum sollten Sie 5 Fuß vor der Ziellinie anhalten und nicht nur alles wegräumen? An diesem Punkt haben Sie keinen Code mehr, der von den Geschäftsentitäten abhängig ist, und Sie können den Kern wirklich freigegebenen Code in dem freigegebenen Projekt belassen. Welches wäre meine Antwort. –

+0

@Chris Das ist keine große Veränderung. Das erfordert ein Refactoring, aber kein großes Redesign oder das Umgestalten von Sachen. –

0

Eine Lösung wäre, ein Fassadenmuster dazwischen zu legen. Hier vermeiden Sie den direkten Zugriff auf Ihre Geschäftsobjekte aus der gemeinsam genutzten Bibliothek. Stattdessen würden Sie eine Ebene verwenden, die als Fassade zwischen Ihrer Bibliothek und BOs fungiert. Auf diese Weise können Sie Ihre freigegebenen Bibliotheken sauber und entkoppelt packen.

+1

Ich würde einfach "Abstraktion" sagen, ohne den Namen eines konkreten Musters zu spezifizieren (es könnte genauso leicht Adapter, Strategie, Brücke sein), weil die Hauptabsicht der Entwurfsmuster nicht darin besteht, Probleme wie diese zu lösen. –

3

Jedes Mal, wenn Sie eine "shared" -Bibliothek haben, dürfen Sie Ihr Business-Entity-Projekt niemals referenzieren. Wenn Sie dies tun, wird dieses Problem so auftreten, wie Sie es offensichtlich sehen. Die Lösung hierfür ist, den gesamten von der Geschäftseinheit abhängigen Code aus der gemeinsam genutzten Bibliothek zu entfernen und entweder die Notwendigkeit für diesen Hilfscode neu zu entwickeln oder diesen Hilfscode innerhalb des Geschäftsentitätsprojekts selbst anzuordnen.