Warum brauchen wir eine gemeinsame Service-Locator-Bibliothek?

Question

Ich habe eine 3-lagige Anwendung. Front, Geschäft, Datenschicht. Ich habe Microsoft Unity als Dependency-Container verwendet. Ich habe NUnit mit RhinoMock verwendet, um die Anwendung zu testen.

Ich habe in vielen Artikeln gelesen, um eine gemeinsame Service Locator Layer einzuführen.
** In welchen Scnerios sollten wir gemeinsame Service Locator einführen?

1. Welche Schicht würde es im Projekt durch die oben beschriebene Architektur ersetzen?

2. In welcher Schicht kommuniziert es in meinem Projekt?

3. Ist gemeinsamen Service Locator Schicht nur ein Web-Service WCF-Projekt, das für Unternehmen und Frontschicht in Verbindung steht? **

Answer 1

Warum brauchen wir gemeinsame Service Locator Bibliothek?

Wir brauchen es nicht wirklich, es bietet nur eine bessere Trennung. Es ist meistens eine Abstraktion oben auf Dependency-Injection, so dass der Client nicht wissen muss, wo sich der Service befindet und wie er implementiert ist.

Dies würde normalerweise zu Ihrem Client-Code gehen. Beispiel: Ein Client, der einen Proxy erstellt und einen Dienst aufruft, muss den Proxy nicht erstellen, sondern fragt ihn von einem Service-Locator ab.

Answer 2

Ich glaube, Sie auf einen gemeinsamen Weg sich beziehen Abhängigkeiten der Lokalisierung (dh Dienstleistungen) In Ihrem Beispiel würde es Unity ersetzen (oder vielleicht würde Unity einfach die gemeinsame Schnittstelle implementieren).

Auf diese Weise alle Arten von Frameworks zusammen leichter etwas funktionieren würde, wie sie/einen gemeinsamen Weg zu identifizieren Dienste teilen Plugins usw.

Wir haben bereits viele Bibliotheken, die die Funktionalität (Unity, Ninject etc.) erreichen , aber wenn ein Framework (zB MVC) eine Instanz einer Schnittstelle erhalten möchte, muss es wissen welche Bibliothek Sie verwenden, und da sie keine gemeinsame Schnittstelle haben, ist dies schwierig. Mit einer gemeinsamen Schnittstelle können Sie MVC sagen, wo Sie wollen, dass es seine Objekte bekommt.