Server-basierte Wiederverwendung - DLL, GAC, oder REST?

Question

Wir haben ein Stück Funktionalität, die von mehreren verschiedenen Anwendungen (Clients) auf dem gleichen Server verwendet wird. Es kann am besten als Service modelliert werden, hat eine Backend-Datenbank, und es wird nur zu einem beliebigen Zeitpunkt eine Version der Funktionalität und die Datenbank im Einsatz sein.

Bisher haben wir einfache DLL-Wiederverwendung verwendet, mit der Funktionalität, die Konfigurationsdatei und Abhängigkeiten überall eingesetzt es verwendet wird. Da nun alle Änderungen müssen vorgenommen mehreren Stellen sein, diese Methode ist schmerzhaft, wenn neue Versionen der Funktionalität erstellt wird oder wenn neue Kunden wollen, es zu benutzen.

Wir fragen, ob es ein besserer Weg, dies zu tun, und haben mit zwei möglichen Alternativen kommen.

1. Setzen Sie die DLL (und die Abhängigkeiten) im GAC. Die Frage ist dann, wie die Komponente zu konfigurieren. Da die Kunden kein Interesse an der Konfiguration haben, lehnen wir uns in Richtung auf dem Server die Konfigurationsdatei in einem hartcodierten Pfad zu speichern.

2. Veröffentlichen, um die Funktionalität als interner (REST-basierten) -Dienst. Der Zugriff darauf kann auf interne Clients mit der Firewall begrenzt werden.

Wie wir es sehen, scheinen die Profis von # 1 Leistung zu sein und möglicherweise die Sicherheit, während # 2 als einfacher gesehen werden einzurichten.

Fehlt etwas Wichtiges hier? in einer ähnlichen Situation ist, bevor jemand gewesen und will einen Einblick teilen?

Answer 1

Dies ist ein Problem, das ich mit oft zu kämpfen haben, und es gibt wirklich keine beste Antwort anderen hängt es dann. Meine persönliche Meinung ist, dass Sie weg von Option bleiben müssen 1 für ein paar Gründe:

1. Indem alle Ihre Kunden eine einzige binäre teilen es jetzt alle Ihre Kunden benötigen jedes Mal, wenn Sie eine Änderung, um es zu prüfen. Jetzt weiß ich, in Ihrem genauen Fall könnten Sie dies sowieso tun müssen, da wir davon ausgehen, können Sie sich auf die Datenbank werden modifizieren, die hinter der Komponente sitzt.
2. Sie keine harten Code nichts. Sie können Ihren Konfigurationspfad in einem AppSettings Abschnitt in der Datei machine.config speichern.

Wie bei Option 2 eine Alternative wäre, WCF zu verwenden (Ihre Umgebung unter der Annahme, es unterstützen kann). WCF verwenden Sie könnten dann einen TCP-Transport mit binärer serilization verwenden (und es könnte ein Shared-Memory-Transport sein). Beides würde dazu beitragen, die Leistungslücke näher zu bringen (Obwohl Option 1 immer einen Service basierten Ansatz übertreffen).

mit der Option 2 Indem wir Sie lindern auch die Notwendigkeit, alle Kunden erneut zu testen, wie Sie automatisierte Tests entwickeln können zu bestätigen, dass Ihr Vertrag nicht gebrochen ist. Dies ermöglicht es Ihnen zu einem Ort, führen schnelle automatisierte Tests zu veröffentlichen, und wissen, dass Ihr die Kunden nicht zu brechen.

Mit dieser sagte Sie die gleiche Sache Option erreichen können 1 und einen guten Satz von Unit-Tests, aber auf Grund meiner Erfahrung Option 2 wird auf lange Sicht einfacher sein.

Option 2 können Sie auch den Service in Zukunft skalieren, wenn Sie jemals mehr CPU-Leistung benötigen.

Ich persönlich denke, Option 1 einfacher aufzusetzen ist, da Sie nicht mit der Konfiguration der Firewall, die Handhabung Authentifizierung, die Einrichtung eines Service etc ... Es wird auch leichter zu debuggen (Verteilen einer Anwendung zu tun haben werden neue die Website Arten von Fehlern zum Beispiel des Hosting Ihres Dienst abstürzt und Ihre Kunden anfangen, Ausfälle).

Ein letzter Vorschlag ist, dass Sie ein Proxy / Fassadenmuster verwenden, um Ihre Kunden von der tatsächlichen Lage des Dienstes insolate. Auf diese Weise können Sie im Laufe der Zeit erweitern, ohne den Client-Code zu ändern.

Answer 2

Als Josh schon gesagt, leider ist die Antwort für diese Art von Fragen ist oft „es kommt“.

Ich bin ein großer Fan des GAC, aber Sie sollten nur dort gesetzt Code, von denen Sie sicher sind, dass es (fast) perfekt funktioniert, und braucht nicht sehr häufig aktualisiert werden. Solange ein Stück Code „in Entwicklung“ ist, nur um es veröffentlichen zusammen mit jeder Anwendung, die es verwendet.

Answer 3

Ich würde sagen, dass 1 Option verwenden wäre einfacher und leichter, zumal youwill müssen nur mehr Zeit verbringen die Verfügbarkeit des REST begrenzen. (Wortspiel beabsichtigt!)

Answer 4

Josh weist darauf hin, WCF als Option, und das ist sicherlich so, wie ich mit dieser gehen würde.

Dieses Problem ist genau das, was SOA soll lösen!