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

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) ist freier Consultant, Trainer, Autor und Speaker.


Seine Schwerpunkte liegen im Bereich der .NET-Architektur, agilen Prozessen und XAML. Er veröffentlichte vor kurzem seine DVD´s mit Video-Trainings zum Thema „Meine erste Windows 8 App“, „Windows Store Apps mit XAML und C#“ und „WPF 4.5 und Silverlight 5“ bei Addison-Wesley von video2brain.


Biswanger ist auch im Auftrag von Intel GmbH als Technologieberater für die Intel Developer Zone aktiv und ist Leader bei der Ingolstädter .NET Developers Group (INdotNET). 

 

Video über mich:
http://www.youtube.com/watch?v=mx_6SiiLxjk


Basta! 2011 Speaker

CLIPer

MCTS
Windows SharePoint Services 3.0 – Application Development (MCTS)