In einer komponentenbasierten Architektur, in der eine große Anzahl von entkoppelten Komponenten über eine Reihe von standardisierten Schnittstellen kommunizieren - gibt es Richtlinien für die Frage, wo und wie die Schnittstellen zu speichern sind?
Extreme Lösungen wären:
Diese beiden Optionen scheinen mir falsch zu sein - die erste ist nicht flexibel genug (zum Beispiel, wenn Sie nur eine Schnittstelle ändern wollen), die zweite ist das andere Extrem, das sehr schnell zu Wartungs-Albtraum eskalieren könnte.
Insbesondere suche ich nach KILLER-Argumenten, um nicht die beiden Extreme und offensichtlich alternative Approchaes zu übernehmen.
Alle Meinungen geschätzt.
Auf den Punkt gebracht Wenn die Schnittstellen gemeinsam genutzt werden, müssen sie in einer gemeinsamen Assembly gruppiert werden, andernfalls müssen sie sich in der Assembly der Komponentenschnittstellen befinden.
Etwas detaillierter Wenn sich eine der standardisierten (d. H. Gemeinsam genutzten) Schnittstellen ändert, egal wo Sie sie platzieren, müssen Sie alle Komponenten, die sie implementieren, ändern, unabhängig davon, ob sich diese Schnittstelle in einer gemeinsamen Baugruppe oder in einer Komponente befindet. Es gibt also keinen spezifischen Nachteil von Option 1, selbst wenn Sie, wie Sie sagen, nur eine einzige Schnittstelle ändern müssen. Auf der anderen Seite hätten Sie einen Nachteil, wenn Sie allgemeine Schnittstellen in jeder Komponente replizieren, siehe Standardredundanzprobleme.
Dies ist kein spezieller Vorschlag, sondern eine natürliche Wahl von dem Moment an, wo Sie (klugerweise) standardisierte Schnittstellen gewählt haben. Du hast dich bemüht, sie zu identifizieren, du hast festgestellt, dass sie Standard sind, und jetzt gruppierst du sie.
Wenn die Komponenten, die diese allgemeinen Schnittstellen implementieren, zusätzlich einige andere Ad-hoc-Schnittstellen haben, müssen diese sich in der Komponentenassembly befinden, da sie nicht den anderen Komponenten zugänglich sein sollen, die Zugriff auf die gemeinsame Baugruppe haben.
>IMO Die Schnittstelle (n) für die Komponente sollten sich mit der Komponente - möglicherweise in einer komponentenspezifischen Schnittstellenbaugruppe - befinden.
Alle "allgemeinen" Datentypen sollten getrennt von den Komponenten existieren (möglicherweise in einer "gemeinsamen" oder "gemeinsamen" Komponente).
Sie würden normalerweise eine Art "gemeinsame" Bibliothek erstellen, auf die alle Komponenten in der Architektur verweisen müssen. Hier werden alle gemeinsamen Schnittstellen, Enums usw. definiert und gruppiert.
Der erste Schritt beim Erstellen einer Bibliothek, die das Framework erweitert oder in das Framework passt, besteht darin, auf die Common.DLL zu verweisen. Sie implementieren dann, welche Gruppe von Schnittstellen Sie in diesem bestimmten Modul benötigen.
Die extremen Lösungen, die Sie beschreiben, sind in der Tat sehr extrem. Die erste wäre sehr unflexibel und im Grunde humpeln die Fähigkeit, Ihren Rahmen zu erweitern. Die zweite wäre sehr flexibel, aber ertränkt Ihr Projekt in einer nervenden Suppe von Single-Interface-DLLs.
Alle sehr gute Antworten. Und ich möchte den allgemeinen Conscensus von "in Maßen" fördern.
Eine kurze Anekdote,
Ich habe persönlich gesehen, dass ganze Lösungen mit einer Zunahme von funktionsspezifischen Baugruppen explodieren. Ich habe auch monolithische Ansätze gesehen. Wiederholen: Sie wollen etwas dazwischen.
In meinen persönlichen Projekten verwende ich viel Dependency Injection [DI] und Inversion of Control [IoC] und nutze Castle Windsor Container, um viel zu tun. Ich bestimme auch frühzeitig, welche Komponenten einen "breiten" Anwendungsbereich erfordern und welche keine Exposition erfordern. Zum Beispiel würde ein Service [sagen der Container selbst oder ein Event-Broker] als "breit" betrachtet werden, da es wahrscheinlich viele viele Konsumenten dieses Service über die gesamte Anwendung gibt. Eine Komponente, die isoliert ist [zB ein geschäftsspezifischer Datumsformatierer], wäre nicht breit, da niemand daran interessiert ist, sie direkt zu konsumieren, außer für das Geschäft, für das sie spezifisch ist.
Breite Schnittstellen, würde ich in eine separate SomeProductName.Interfaces -Assembly legen.
Geschäftsspezifische Schnittstellen können in ihrer eigenen funktionsorientierten Assembly SomeProductName.SomeStuffForAlice und SomeProductName.SomeStuffForBob platziert werden, typischerweise dieselbe Bibliothek wie ihre Implementierung.
Baugruppen sind nur eine physische Repräsentation der Quellenorganisation - sie bedeuten eigentlich nichts in und für sich [dh ein monolithischer Brei, obwohl abstossend, ist funktional äquivalent zu einer gut organisierten Lösung und dem störenden Projekt pro Interface-Albtraum].
Eine Organisationsvereinbarung ist nur dann sinnvoll, wenn sie ihren Kunden [Sie! der Entwickler!]
Können Sie die Schnittstellen nicht in funktionale / Domänenbereiche gruppieren? Auf diese Weise würden Sie irgendwo in der Mitte eine Lösung finden. Wenn nicht, würde ich alle gängigen Schnittstellen in nur eine Baugruppe einfügen.
Ich verwende so wenig Baugruppen wie möglich, um eine einzelne Baugruppe zu erzeugen und flüchtige Bereiche der Domäne zu isolieren. Wenn mehrere Baugruppen eindeutig geeignet oder erforderlich sind, tue ich mein Bestes, um Schnittstellen zu gruppieren, die sich gleichzeitig in dieselben Baugruppen ändern.
In letzter Zeit gab es eine gute Diskussion über die Kosten für die Wartung mehrerer Baugruppen. Dieser Artikel eignet sich besonders gut, um die Nachteile mehrerer Baugruppen zu beschreiben und zu beobachten, wie diese zu zusätzlichen Kosten führen zur Entwicklungszeit, Kompilierzeit, Bereitstellungszeit und Laufzeit.
Es hängt vom Zweck jeder Schnittstelle ab:
Wenn der Zweck der Schnittstelle darin besteht, ein Standardprotokoll zwischen einer Reihe alternativer Lieferanten und einem einzelnen Verbraucher zu definieren, gehört die Schnittstelle dem Verbraucher.
Wenn der Zweck der Schnittstelle darin besteht, ein Standardprotokoll zwischen einem einzelnen Lieferanten und einer Gruppe alternativer Verbraucher zu definieren, gehört die Schnittstelle dem Lieferanten.
Wenn der Zweck der Schnittstelle darin besteht, ein Standardprotokoll zwischen einer Reihe alternativer Lieferanten und einer Gruppe alternativer Konsumenten zu definieren, steht die Schnittstelle für sich selbst.
Wenn schließlich Schnittstellen als allgemeiner Ansatz zur Verringerung der Komplexität verwendet werden, gehören sie in der Regel den Verbrauchern und sollten so eng wie möglich definiert werden, so dass jede Schnittstelle die Bedürfnisse des Verbrauchers in spezifischen Anforderungskontexten unterstützt.
Tags und Links .net architecture interface components