Ressourcen für das Entwerfen von .dll-Struktur

Question

Ich kam gerade aus einem Design-Meeting und hatte eine Frage an mich, wo ich eine meiner Ideen zur Strukturierung von .dlls eines Projekts, das wir bauen, hatte. Um ehrlich zu sein, ich habe keine Ahnung, woher diese "Idee" kam, sie erschien mir einfach als natürliches Wissen. Es wäre jedoch nützlich, wenn ich diese Meinungen mit einer dokumentierten Analyse untermauern könnte.

Kennt jemand irgendwelche Ressourcen, die explizit verschiedene Mechanismen zur Strukturierung von Baugruppen/Modulen/Quelle diskutieren?

UPDATE:

Nun, die Idee war nichts Besonderes. Wir diskutierten eine Abstraktionsschicht für einige Hardware, so dass die "App", die diese Dienste in Anspruch nimmt, plattformunabhängig sein könnte. Zuvor hatten wir eine Schnittstellen-DLL, die die von der App benötigten Schnittstellen deklariert, und eine Implementierungs-DLL, die sie für die eine Plattform implementiert, die wir bisher hatten. Jetzt haben wir zwei Plattformen, aber sie sind sehr ähnlich. Um zu verhindern, dass die .dll-Interfaces verschmutzt werden oder ein scheußliches Szenario, in dem sich die Implementierungen gegenseitig referenzieren, schlug ich lediglich vor, eine weitere .dll zu erstellen, die zwischen den Interfaces und spezifischen platform.dlls liegt, wo gemeinsame abstrakte Implementierungen leben können.

Answer 1

Wenn Sie eine Chance haben, einen Blick auf das Buch von Robert C. Martin:

Agile Principles, Patterns, and Practices in C# (Dies ist die neue Version speziell auf .Net gezielte)

Es gibt ein Kapitel zur Komponente gewidmet Design, das (wahrscheinlich) Ihre Frage beantwortet.

Zusammengefasst und nach diesem Buch zu lesen, empfehle ich Trennung Komponenten immer von diesen Kriterien:

• Baugruppen Einheiten sind oder verwendet werden können: Wenn es Klassen gibt, die zusammen verwendet werden, werden sie müssen gehen in der gleichen Versammlung.

• Baugruppen sind Einheiten der Änderung: Wenn es Klassen gibt, die aus dem gleichen Grund nicht geändert werden müssen, sollten sie wahrscheinlich nicht in derselben Baugruppe sein.

Baugruppen sind Einheiten der Bereitstellung: Wenn es Klassen gibt, die physisch am selben Ort bereitgestellt werden müssen, sollten sie wahrscheinlich in derselben Baugruppe gehen.

Natürlich sind dies nur Heuristik und nicht die Rezepte. Je nach den architektonischen Zielen Ihrer Anwendung (insbesondere den architektonischen Zielen für die Bereitstellung und Entwicklung/Modifikation) müssen Sie schließlich entscheiden, wie viel von jeder dieser drei Design-Heuristiken Sie benötigen.