C# Schnittstellen in eigene Assembly?

[Ghost_Rider_R]

Hallo zusammen,

ich frage mich gerade, ob es dem CleanCode-Gedanken entspricht, wenn Schnittstellen in einem eigenem Assembly ausgelagert werden.

Ich habe z.B. die folgenden Klassen:

DatenbankAPI -> IDatenbankAPI
DienstManager -> IDienstManager
PersonalManager -> IPersonalManager

usw.

Die Klassen haben teilweise nichts miteinander zu tun, da Sie in unterschiedlichen Projekten verwendet werden. Teilweise greifen Sie aber auch über Schnittstellen auf andere Klassen zu, da notwendige Abhängigkeiten bestehen.

So nun die Frage:
Sollte ich die ganzen Schnittstellen (IKlassennameXYZ) pauschal immer in einem eigenen Assembly z.B. die Klasse Schnittstellen sammeln und darauf referenzieren?
Oder gehört eine Schnittstelle immer in das Assembly, in der die ursprüngliche Implementierung liegt?

Vielen Dank für eure Hilfe.

LG Ghost.

 

[tollertyp]

Ein klares: Es kommt drauf an.

Es spricht an und für sich nichts dagegen, eine Schnittstelle als eigenes Artefakt (Assembly) zu releasen - siehe JavaEE.
Wenn man allerdings sowieso nur eine Implementierung dieser Schnittstelle hat, bzw. nur in Ausnahmen spezielle Implementierungen, kann das auch Overkill sein. Und auch, wie stabil die API ist, wenn sich die API alle Nase lang ändert, würde ich wohl eher kein eigenes Artefakt machen.

Die reine Lehre würde vermutlich ein eigenes Artefakt bevorzugen, aber es gilt halt auch: If you know the rules, break them.

 

[Ghost_Rider_R]

Über weitere Meinungen würde ich mich dennoch freuen 😊

 

[KitKat::new()]

Sollte ich die ganzen Schnittstellen (IKlassennameXYZ) pauschal immer in einem eigenen Assembly z.B. die Klasse Schnittstellen sammeln und darauf referenzieren?

nein

Warum Dinge unnötig komplizierter machen?
Mach es, wenn du es brauchst, ansonsten lass es.

 

[tollertyp]

Eben, es sollte schon einen Mehrwert bringen und nicht nur mehr Aufwand bedeuten.

 

[dermoritz]

Sehe ich ähnlich: Sobald man die Schnitztstellen "publishen" will und sie ggf ihren eigenen Lebenszyklus (Verisonen) haben würde ich sie auslagern.
Bis dahin alles so lassen wie es ist. Oder allgemein: Möglichst nur Aufwand in Dinge stecken die jetzt einen Mehrwert bringen. (An die Zukunft denken nicht übertreiben)

 

[Ghost_Rider_R]

Das ist ja höchst Interessant. Über weitere Meinungen würde ich mich sehr freuen.

 

[marcOcram]

Ich handhabe es so, dass die Schnittstellen eigentlich immer mit in die Assembly der Standard-Implementierung kommen solange die Implementierung keine externen Bibliotheken benötigt.

Beispiel #1: IDatenbankAPI abstrahiert den Zugriff auf eine Datenbank. Da die Implementierung SqlServerDatenbankAPI auf Microsoft.Data.SqlClient referenziert wird diese in eine separate Bibliothek (Assembly) gepackt. Eine Implementierung für Oracle soll dann nicht den Ballast vom SqlServer mitschleifen. Daher separate Bibliothek.

Beispiel #2: Ich habe das Interface IAmUseless und die (Standard-)Implementierung ReallyUseless. Da ich keine Abhängigkeit zu externen Bibliotheken habe, kommt das der Einfachheit einfach mit in die selbe Bibliothek (Assembly).

Beispiel #3: Das Interface IExcelReader referenziert eine externe Bibliothek. Die Implementierung kommt in die selbe Bibliothek weil das Interface die Abhängigkeit bereits vorgibt.

 

[tollertyp]

Ja, unnötige transitive Abhängigkeiten (also unnötige Abhänigkeiten, die durch andere Abhängigkeiten implizit entstehen) sollten vermieden werden.

 

[Ghost_Rider_R]

Ich denke @marcOcram hat es sehr gut und für mich nachvollziehbar beschrieben. Diesen Weg werde ich künftig einschlagen. Vielen Dank euch allen für eure Hilfe!