Web-Service und die Datenschicht – Alles nur Facade?

by Gregor Biswanger 1. Januar 2009 12:23

Ein Web-Service bietet für die Kommunikation zur Datenbank viele angenehme Vorteile. Gerade von Fremdanbietern kann infolgedessen eine Integration in das eigene Solution-Projekt beschwingt integriert werden. Visual Studio bietet dafür einen leichtgewichtiges O/R-Mapping, damit wird der Web-Service auch als Objekt zur Verfügung gestellt. Genau dasselbe Prinzip wie LINQ-to-SQL oder LINQ-to-Entity.

Web-Service in eine bestehende Architektur

Nun muss nur noch überlegt werden, WO der Web-Service in eine bestehende Architektur aufgenommen wird. Ein Web-Service bietet uns einen Zugriff auf externe Daten an, dementsprechend kommt er in die Datenschicht auch DataAccessLayer(DAL) genannt.

Nur auf dem ersten Blick

Doch werden uns nur die Vorteile vorgespielt? Wir haben hier mehrere Probleme! Zum ersten werden uns zwar Entitie-Objekte bereitgestellt, doch haben wir extern zum Beispiel von der Business-Logik gar keinen Zugriff darauf. Als zweites Problem ist die Vorgegebene Architektur der zur Verfügung gestellten Objekte. Meist beinhalten Sie zahlreiche Klassen und Methoden, die auch über keine Interfaces (Schnittstellen) verfügen. Das Kopfzerbrechen beginnt! Wie bekommt man einen Web-Service architekturneutral integriert?

Der richtige Weg?

Ein Web-Service in eine bestehende Architektur einzubinden, wird ein immer wiederkehrendes Problem sein. Genau dafür gibt es die Design-Patterns (Entwurfsmuster)! Der erste Gedanke dabei, wäre sofort das Adapter- oder Command-Pattern. Doch muss für das erste einmal ein Interface (Schnittstelle) bereitstehen und beim zweiten wird der Aufwand enorm groß. Es darf auch nicht vergessen werden, dass die Web-Services zudem geändert werden können. Womit die eigene Applikation nur mit hohem Aufwand wieder abgeändert werden muss.

Alles in Facade!

Dafür gibt es das Facade-Pattern, es ist dem Adapter sehr ähnlich. Die Facade ist nichts anderes wie eine Hauptklasse, die für die Kommunikation der Objekte des Web-Services bereit steht. Jede Methode greift auf eine Funktion zu. Bei der Fertigstellung der Facade, sollte Sie durch ein Interface für die Business-Logik zur Verfügung stehen. Rückgabe werte sollten mit eigenen Entities in der Facade gefüllt werden. Die Entities stehen in der Infrastructur-Schicht für alle anderen Schichten bereit.

Abb. 1: Diagramm vom Facade-Pattern in der Datenschicht (DataAccessLayer) in einer .NET-Architektur

Die offizielle Beschreibung der Facade (GoF) lautet:

"Biete eine einheitliche Schnittstelle zu einer Menge von Schnittstellen eines Subsystems. Die Fassadenklasse definiert eine abstrakte Schnittstelle, welche die Verwendung des Subsystem vereinfacht."

Fazit

Die Facade hilft uns hier bei der Integration vom Web-Service sehr schnell weiter. Die Trennung findet nur sauber unter den Schichten statt, doch die Logik vom Web-Service wird nicht aufgeteilt. Das ist auch nicht besonders Relevant, da unsere Facade als Vermittler (Service) ein gutes Bild macht.



Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.
kick it on dotnet-kicks.de

Kommentare

Kommentar schreiben


(Zeigt dein Gravatar icon)  

  Country flag

biuquote
  • Kommentar
  • Live Vorschau
Loading



Powered by BlogEngine.NET 1.4.5.0
Theme by Extensive SEO

Über den Autor

Gregor Biswanger

Microsoft MVP für Client App Dev
XING

Gregor Biswanger (Microsoft MVP für Client App Dev) arbeitet als Solution Architect und XAML Experte bei der Firma impuls Informationsmanagement GmbH aus Nürnberg.


Seine Schwerpunkte liegen im Bereich der .NET-Architektur, XAML und agilen Prozessen. Er veröffentlichte vor kurzem seine DVD mit Video-Trainings zum Thema „WPF 4 und Silverlight 4“ bei Addison-Wesley von video2brain.


Biswanger ist auch freier Autor, Speaker und Microsoft CLIPler der INdotNET (Ingolstädter .NET Developers Group). 



Basta! 2011 Speaker

CLIPer

MCTS
Windows SharePoint Services 3.0 – Application Development (MCTS)