Web-Services haben sich in Laufe der letzten Jahre sehr etabliert. Ist ja auch kein Wunder, sie bringen auch eine Handvoll von Vorteile mit sich. Durch den allgemeinen WSDL-Standard, kann eine externe Kommunikation der Daten, durch unterschiedliche Technologien konsumiert werden. Es spielt am Ende keine Rolle mehr, ob der Client nun eine .NET oder Java-Applikation ist. Dennoch sind Web-Services nicht nur wegen Ihrer Flexibilität so beliebt, sondern auch an der einfachen Implementierungsunterstützung der einzelnen IDE´s.

Wie bereits beim Blog-Artikel „Web-Service und die Datenschicht – Alles nur Facade?„ - kann der Zugriff der Server-Daten einfachst über eine Facade zur Verfügung gestellt werden. Erfahrungsgemäß ist hier zu jeder Anforderung ein CRUD (Create, Read, Update und Delete) zu Programmieren. Das bringt viel an Pflege und Arbeit mit sich. Viele Entwickler kämpfen bereits Täglich mit diesem Problem. Doch wie bereits in zahlreichen Artikeln von mir geschildert, gibt es zu immer wiederkehrenden Problemen meist ein Entwurfsmuster „Design-Pattern“. In diesem Fall würde ein Unit-of-Work-Pattern, die Anforderungen mit einem CRUD perfekt abdecken.

Nun wäre es ein perfekter Lösungsweg, die Facade des Web-Services mit einem Unit-of-Work-Pattern auszustatten. Doch bevor man sich Gedanken um die Umsetzung macht, soll ein Blick auf bisherige Technologien geworfen werden. Sehr Modern ist derzeit die Datenkommunikation mittels REST “Representational State Transfer“. REST ist eine Technologie, die von Anlauf des Internet Zeitalters existiert. Denn jede Kommunikation vom Browser zum Web-Server geschieht mittels REST beim HTTP-Protokoll. REST stellt für diese Kommunikation genau genommen eine Unit-of-Work-Lösung bereit, demnach wird hier als flexibler weg ein CRUD zur Verfügung gestellt. Der Hauptsächliche nutzen von REST fand durch das Aufrufen der Websites im Adress-Zeilen Bereich mittels URL statt, oder das versenden von Formularen (Post). Unterdessen bei einer solchen abfrage bisher kaum Daten zur Kommunikationsbeschreibung gebraucht werden, wie zum Beispiel eine XML-Definition bei WSDL (Web-Services), ist REST auch noch sehr Performant. Weil hier eine umfangreiche Kommunikationsbeschreibung erspart bleibt. Das einzige Problem steht hierbei nur im Weg, wenn ein fester Aufbau eines Web-Services mittels REST von unterschiedlichen Anbietern konsumiert werden soll, fehlt die erleichterte WSDL-Definition.

ADO.NET Data Service erstellen

Mit dem .NET-Framework 3.0 ist eine neue Kommunikationstechnologie mitgekommen, die Windows Communication Foundation (kurz WCF). Mit WCF lassen sich Kommunikationen erstellen, die nachträglich flexibel eingesetzt werden können. Es spielt später keine Rolle mehr, ob eine Kommunikation noch über ein Web-Service oder Socket stattfindet. Zudem bringt WCF noch einiges mehr mit sich, obwohl Web-Services Asynchron verarbeitet werden, kann ein Client von Web-Service aufgerufen werden.

ADO.NET Data Service ist mit dem .NET-Framework 3.5 gemeinsam mit dem Entity-Framework und LINQ dazugekommen. ADO.NET Data Service basiert auf WCF und ist für das bereitstellen von Entity-Framework-Modellen konzeptioniert worden. Dabei werden die Modelle automatisiert als Web-Services zur Verfügung gestellt. Der Web-Services bietet das komplette CRUD mittels REST an.

Um das besser zu verbildlichen, erzeugen wir ein neues Projekt „ASP.NET Web Application“ mit dem Namen ADONETExample.WebDAL, und der Solution Name lautet: ADONETExample (siehe Abb.1.1).

Abb.1.1. – Neues „ASP.NET Web Application“-Projekt in Visual Studio erstellen.

Als nächstes wird die zur Verfügung gestellte Default.aspx-Datei gelöscht, und dem Projekt ein neues Verzeichnis mit Model erzeugt. In das Verzeichnis Model muss nun ein neues Item hinzugefügt werden (siehe Abb.1.2).

Abb.1.2. – Neues Item hinzufügen.

Hier erzeugen wir uns ein neues ADO.NET Entity Data Model. Damit wird vom Entity-Framework (O/R-Mapper) ein Abbild der Datenbanktabellen als Klassen erzeugt. Bei dieser Demo wird die Beispieldatenbank Northwind von Microsoft eingesetzt. Daher wird der Name auf NorthwindModel vergeben.

Abb.1.3. – ADO.NET Entity Data Model erzeugen

Daraufhin wird ein Wizard angezeigt, womit „Generate from database“ ausgewählt wird, da ein Abbild von einer Datenbank erwünscht ist. Dann muss unter „New Connection“ die erwünschte Datenbank ausgewählt werden.

Abb.1.4. – Überblick der Datenbank verbindung

Als nächstes Zeigt und der Wizard alle Verfügbaren Funktionen der Datenbank an, die mit in das Model zur Verfügung gestellt werden können. Das wären: Tables, Views und Stored Procedures. Für diese Demo reichen Tabellen vollkommen aus.

Abb.1.5. – Nur Tabellen werden ausgewählt

Beim bestätigen auf „Finish“ wird vom Entity-Framework alles Nötige Generiert und eine Übersicht vom Model wird Grafisch im Designer-Modus dargestellt. Hier könnten nun weitere Einstellungen für das Model durchgenommen werden. Das kann allerdings auch jederzeit im Projekt, durch ein Doppelklick auf die Model-Datei ausgeübt werden.

Abb.1.6. – Entity-Model im Designer dargestellt

Jetzt wird der Designer geschlossen und zum Solution Explorer gewechselt. Dort ist nun unter dem Verzeichnis Model das Entity-Model NorthwindModel.edmx zu finden. Ein Blick auf die Code-Behind Datei NorthwindModel.Designer.cs unterhalb von NorthwindModel.edmx, zeigt die einzelnen Tabellen als Klasse abgebildet. Womit später ganz bequem darauf zugegriffen werden kann. Doch jetzt wird sich prämier auf das ADO.NET Data Service konzentriert.

Abb.1.7. – Code-Behind-Datei vom Entity-Model

Unsere Web-Service-Datenschicht: ADONETExample.WebDAL, benötigt nun das ADO.NET Data Service als neues Item. Dazu wird ein rechtsklick auf ADONETExample.WebDAL gemacht und auf New Item geklickt. Dort wählt man ADO.NET Data Service und vergeben den Namen: WebDataService.svc

Abb.1.8. – ADO.NET Data Service hinzufügen

Nach dem erzeugen des ADO.NET Data Services, öffnet sich der Source-Code. Hier werden einfachst durch Kommentare beschrieben, welche Schritte hier durchgeführt werden müssen. Als erstes müssen wir in den eckigen Klammern, bei der Basisklasse DataService unser Entity-Model überreichen. Also schreiben wir hier: NorthwindEntities. Damit NorthwindEntities auch vom Verzeichnis Model gefunden werden kann, darf das Using zum Namespace nicht vergessen werden: using ADONETExample.WebDAL.Model;

Abb.1.9. – Das Entity-Model dem ADO.NET Data Service bekannt machen.

Die nächste Aufgabe ist eine etwas aufwändigere Angelegenheit. Beim Instanziieren des Web-Services wird beim Konstruktor die Configuration übermittelt, womit hier noch einmal Manuell bestimmte Konfigurationen, wie zum Beispiel das Thema Sicherheit behandelt werden kann. Wichtig! Die Konfiguration benötigt eine Definition der Sicherheit. Daher müssen explizit für die Entities und den Services die Regeln definiert werden. Wir greifen auf den Parameter config zu und setzen für beide Methoden SetEntitySetAccessRule und SetServiceOperationAccessRule die Regeln fest. Nun muss erstens der Name des Entities zum Beispiel „Customer“ aus dem Entity-Model als String geschrieben werden. Doch für dieses Demo geben wir hier nur ein „*“ mit, das soviel bedeutet: „Diese Regel für ALLE Entities“. Danach kann eine explizite Regel dafür eingestellt werden mittels des enum EntitySetRights. Die Regeln die gesetzt werden können sind: Nur Lesen, Nur Schreiben, Kompletter Zugriff uvm. Hier wählen wir den Punkt: ALL.

Dieselbe Regelung definieren wir auch für die SetServiceOperationAccessRule, danach wäre unser ADO.NET Data Service fertig. Bei einem richtigen Unternehmensscenario muss auf jeden Fall genügend Zeit für die Sicherheitdefinition investiert werden, und sollte daher kein „*“ zum Einsatz kommen. Um ein besseres Bild zu bekommen, siehe Abb. 1.10.

Abb.1.10. – ADO.NET Data Service – Regeln für den Zugriff Definieren.

Der ADO.NET Data Service wäre Fertig! Um die REST Funktionalitäten zu testen, kann das Projekt mittels [F5]-Taste gestartet werden. Das Projekt wird gebuildet und der Web-Service im Browser gestartet. Es werden alle Tabellen aus unserem Entity-Model als XML dargestellt. Für die XML Darstellung verwendet das ADO.NET Data Service den allgemeinen Standard ATOM.

Abb.1.11. – Web-Service zeigt Tabellen als ATOM (XML) auf dem Browser an.

REST Funktionalität Testen

Um nun die ersten REST-Funktionalitäten über URL zu nutzen, muss beim Internet Explorer die automatisierte Anzeige von RSS-Feeds deaktiviert werden. Da ATOM ein Standard für Feeds bedacht war. Dazu muss man beim Internet Explorer unter Extras – Internetoptionen – Inhalte – (Feeds) Einstellungen. Dann den Hacken „Feedleseanzeige einschalten“ deaktivieren.

Abb.2.1. – Internet Explorer für REST-Test vorbereiten.

Als erstes soll der Inhalt der Tabelle „Customers“ angezeigt werden. Dazu erweitern wir die URL mit dem Namen „/Customers“. Nach dem bestätigen mit ENTER wird der Browser mit dem Inhalt von „Customers“ neugeladen.

Abb.2.2. – Tabelle „Customers“ mit REST abfragen.

Wenn nun ein einzelner Customer mit seiner ID angezeigt werden soll, muss dementsprechend in Klammern die ID übergeben werden. Geben wir einmal „/Customers('ALFKI')“ ein, um explizit diesen Benutzer zu sehen.

Abb.2.3. – Einzelne abfrage eines Customer mittels ID.

Die abfragen können beliebig nach Wunsch weitergeführt werden. Das besondere an unserem Web-Service ist, das keine Zeile Code für deren Funktionalität geschrieben werden musste. Bis auf das Definieren des Modells und die Konfiguration der Sicherheit.

Alle anderen Funktionalitäten, wie das Updaten, Löschen oder Erstellen, können mit Visual Studio Unterstützung einfachst in Clients verfügbar gemacht werden. Bei Projekten wie WPF oder Silverlight, übernimmt das Data-Binding diese eleganten Aufgaben.

Fazit

REST findet an seiner einfachen und fertigen Einsatzmöglichkeit an hoher Beliebtheit. Was mich persönlich total freut, ADO.NET Data Service ist nicht nur auf das Entity-Framework beschränkt! Eigene Modelle oder Modelle anderer O/R-Mapper wie NHibernate können gleichermaßen zum Einsatz kommen. Es muss nur ein Interface IUpdatable implementiert werden. Zugegeben, es gibt dann noch ein paar weitere Schritte die gemacht werden müssen, aber deren Aufwand ist nicht gleichzustellen, als wenn man eine Unit-of-Work-Lösung selbst schreiben müsste.

Immer mehr Projekte beginnen mit WPF- oder Silverlight-Clients. Deren Data-Binding Funktionalität mit ADO.NET Data Service enorm mächtig machen.

Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.