2009-06-10 6 views
9

Seit einigen Monaten arbeite ich an Projekten in den neuesten dot net Frameworks.Welche Vor- und Nachteile hat der Einsatz von Services gegenüber Komponenten?

Ich fühle, dass in den neuesten dot net-Versionen "Dienste" über Komponenten gefördert werden. Ist das korrekt?

Ich habe in Silberlicht gesehen (ich bin ein Anfänger in Silberlicht) alle DB-Schicht Operationen sind als Dienste ausgesetzt. Ich weiß nicht, jetzt sind auch Komponentenprogramme verfügbar?

Was sind die Vorteile? Was ist mit der Leistung, wenn alle Schichten als Dienste anstelle von DLLS verfügbar gemacht werden?

Bitte durch etwas Licht zu diesem Thema, wo soll ich anfangen, dieses Konzept richtig zu verstehen?

Dank

SC

+0

Nun, im Fall von Silverlight, Ihre UI/App läuft auf dem Client-Rechner in oder aus dem Browser, während Ihre Geschäftslogik auf einem Remote-Server ist. Sie können dies nicht wirklich mit Click-together-Komponenten erreichen - Dienste (die Maschinengrenzen überschreiten) sind wirklich die einzige Möglichkeit, hier zu gehen. –

Antwort

16

Es ist wirklich alles mit einer serviceorientierten Architektur zu tun - etwas, das für eine Weile und ist sehr beliebt üblich gewesen ist.

Die Idee ist, dass verschiedene Operationen voneinander entkoppelt sind, so dass sie wiederverwendet und geändert werden können, ohne die Apps neu zu kompilieren, die sie verwenden. Anstelle eines Stücks Code in einer DLL, das überall modifiziert und kopiert wird, kann ein Dienst bereitgestellt werden, der einen einzelnen Zugangspunkt für eine bestimmte Verarbeitungseinheit oder Informationsquelle darstellt.

Angenommen, Sie hatten eine Kreditkartenprüfkomponente. Sie können diesen Code schreiben und ihn in eine DLL kompilieren und in all Ihren Anwendungen einbinden. Nichts ist falsch daran, es sei denn, Sie bemerken einen Fehler oder die Regeln für die CC-Validierung ändern sich. Oder vielleicht möchten Sie es aktualisieren, um es gegen eine Blacklist zu überprüfen. Sie können keines dieser Dinge tun, ohne die Apps neu zu kompilieren, die es verwenden.

Wenn Ihre Kreditkartenvalidierung jedoch als Dienst verfügbar gemacht wird, können Sie die Änderungen vornehmen und an einem Standort bereitstellen. Vorausgesetzt, die Signatur ist dieselbe (gleiche Parameter und gleiche Antwort), müssen die Anwendungen nicht einmal wissen, dass sie sich geändert hat.

Ein weiterer Vorteil der Verwendung von Diensten über Komponenten ist, dass die Dienste überall gehostet werden können. Sie können auf dem lokalen Server oder auf der anderen Seite der Welt sein.

Nachdem dies gesagt wurde, wie Sie sollten die Architektur von Fall zu Fall entscheiden. Während die Kreditkartenvalidierung ein gutes Beispiel dafür war, wann ein Dienst nützlich ist, macht es keinen Sinn, einen Dienst zum Rendern von HTML-Steuerelementen bereitzustellen.

7

Etwas anderes zu beachten - nur weil Funktionalität als "Service" offengelegt wird, heißt das nicht, dass sie irgendwo gehostet oder als Webservice verfügbar gemacht werden muss.

Sie könnten sehr gut direkt auf einen Dienst zugreifen, im Speicher.

Bei der Bereitstellung verwandter Funktionen als Dienst geht es mehr um die Interaktion zwischen verschiedenen Teilen Ihrer Anwendung. Es sagt nichts darüber aus, wie Sie diese Teile bereitstellen/auf sie zugreifen.

2

"Cross-Language" -Kompatibilität ist ein weiterer Vorteil. Sie können einen Dienst in C# .net schreiben, auf den auch von Java aus zugegriffen werden kann. Die Wiederverwendung geht also über die Verwendung der Programmiersprache hinaus.

Was sind die Vorteile?Was ist mit der Leistung, wenn alle Schichten als Dienste anstelle von DLLS ausgesetzt sind?

Ich würde diesen Punkt hier beachten. Was meinst du mit "alle Schichten"? Anwendungsschichten wie Business und Data Access Layer ?? Ich bezweifle, dass dies nützlich sein kann (natürlich hängt es von Ihrem Kontext ab), aber normalerweise ist ein Service etwas, das in vielen verschiedenen Kontexten wiederverwendet werden kann. Ein Beispiel könnte ein Dienst zur Validierung des Steuercodes sein. Sie würden diesen Service dann über die Business-Schicht Ihrer Anwendung aufrufen. Ich kann mir keinen Fall vorstellen, bei dem Sie die Business-Schicht als separaten Dienst und die Datenzugriffsebene als eine weitere separate Schicht darstellen würden. Normalerweise sind sie sehr spezifisch für Ihre Anwendung, die Sie entwickeln. Es könnte sein, dass Sie eine Anwendung haben, die beispielsweise über das Web (als Webanwendung) zugänglich ist, und über einen Webdienst gibt es einen anderen Einstiegspunkt, den andere Apps verwenden können (eine Art API). Das wäre sinnvoll, allerdings würden Sie Ihre Business-Schicht nicht direkt verfügbar machen, sondern stattdessen eine Art "Gateway" erstellen, bei dem es sich um Ihren Webservice handelt (eine leichtgewichtige Fassade, die an Ihre Geschäftslogikklassen delegiert).