Ghost_Rider_R schrieb:1. Klassen dürfen grundsätzlich fast immer und überall bekannt sein und müssen dies auch, sonst kann man damit ja nicht arbeiten. Diese sollten beim Schichtenmodell so also nicht direkt betrachtet werden, die Klasse String oder DateTime verwende ich ja auch ständig, ich denke so eine Abhängigkeit ist nicht mit dem Schichtenmodell gemeint.
Nahezu alles sind Klassen. Wenn du aber allgemeine Objekte ohne große Businesslogik meinst, dann liegen diese in einem extra Projekt (Im Beispiel unter
Dependency.Common
) und können von jedem anderen Projekt beliebig referenziert werden. Das sind quasi die komplexeren Varianten von Datetime/String und sie werden manchmal auch POCO genannt.Ghost_Rider_R schrieb:2. ... Sollte zwei Klassen in einer darunterliegenden Schicht das selbe Objekt benötigen z.B. eine DB-Verbindung, so kann das selbe Objekt auch an mehrere Zweige durchgereicht werden, sodass zwei Klassen das selbe Objekt verwenden können.
Ob es wirklich das gleiche Objekt oder aber eine neue Instanz ist, wird beim Registrieren der Klasse in der DI festgelegt (Stichwort: Transistent, Singleton, Scoped). Meine Empfehlung ist, konsequent Constructor-Injection zu nutzen.
Ghost_Rider_R schrieb:3. Verwende wenn möglich immer Interfaces, sodass die dahinterliegende Implementierung austauschbar bleibt.
Kein Muss. Wenn die Implementierung nie ausgetauscht wird, erhöht es nur sinnlos die Komplexität.
Ghost_Rider_R schrieb:4. Das Schichtenmodell bezieht ...
Siehe 1.
Ghost_Rider_R schrieb:5. ... ich möchte für jede zusammenhängende Funktion eine eigene Bibliothek erstellen, welche ich dann bei diversen Anwendungen wiederverwenden kann. So z.B. eine Bibliothek für DB-Zugriffe, eine für REST-API zugriffe, eine zum einlesen von Excel-Daten, eine Klasse ,,Konvertierung", welche bei mir häufig verwendete Konvertierungsfunktionen bereitstellt etc.
Das ist üblich (siehe NuGet) und läuft dann als Third-Party-Library, die von deiner Businesslogik verwendet wird.
Zuletzt bearbeitet: