Wohin gehören die Schnittstellen in einer mehrschichtigen Anwendung?

Question

Nehmen wir an, Sie haben eine dreistufige Anwendung mit den Stufen UI, Dienste und Repository für eine einfache Anwendung, z. B. zum Speichern von Adressen.

Wenn AddressService eine Schnittstelle IAddressService hat, wo gehört diese Schnittstelle hin? Ich weiß, dass "im Adressdienst" eine offensichtliche Antwort zu sein scheint, aber wenn es im Adressdienst ist, scheint es den Sinn der Schnittstelle zu vereiteln, so dass jede beliebige Dienstbibliothek eingefügt werden kann, solange sie IAddressService implementiert.

(speziell dies ist in einem .net-Problemraum, aber es ist wahrscheinlich allgemeiner, so dass es Architektur getaggt ist)

Answer 1

Die Adressdienstgruppe ist der richtige Ort dafür.

wenn es im Adressdienst steht würde es den Sinn von die Schnittstelle so zu haben, dass jeder Dienstbibliothek eingefügt werden kann, solange solange sie IAddressService implementiert

Der Sinn der Schnittstelle besteht darin, dem Aufrufer die Möglichkeit zu geben, alternative Implementierungen auszutauschen. Das Anbieten einer konkreten Implementierung (oder mehrerer Implementierungen) beeinträchtigt dies in keiner Weise.

Das einzige Mal, dass ich eine reine Schnittstellen-Assembly erstellen würde, ist, wenn ich keine Implementierung bereitstelle.

Answer 2

Fügen Sie sie in eine separate Baugruppe ein, z. B. AddressService.Interfaces o AddressService.Contracts die von allen drei Ebenen gemeinsam genutzt wird.

Answer 3

Ich neige dazu, sie in der entsprechenden Baugruppe in einem Unter-Namensraum/Verzeichnis abzulegen.

Zum Beispiel, wenn ich eine Kunden Assembly dann ICustomerRepository oder ICustomerAddressRepository etc würde unter gehen

..Customers.Interfaces.ICustomerRepository

Answer 4

Früher habe ich die Serviceschnittstellen in eine Baugruppe und die Implementierung in eine andere gestellt. Ich brauchte es nie in .NET, aber ich tue es trotzdem, ich denke, es ist ein Weg, um die UI (oder ahother API-Client) von Service-Implementacion zu entkoppeln.

Ich brauchte diese Trennung in einem Java-Projekt, in dem ein Applet einen Webdienst aufrufen musste; also wurde nur das jar mit den Schnittstellen an den Browser geschickt. Wenn das Jar auch die Implementierung enthalten hätte, wäre es ein schweres Applet geworden.