Sie sind hier
WCF Data Service (WCF DA)
Eintrag zuletzt aktualisiert am: 09.09.2016
In der ersten Version "ADO.NET Data Service" (Codename "Astoria") - seit dem 18.11.2009 "WCF Data Services", was für die zweite Version gilt (in .NET 4.0)
VersionsgeschichteVersion
Bezugsquelle
1.0
.NET 3.5 Service Pack 1
4.0
.NET Framework 4.0
5.0
http://www.microsoft.com/de-de/download/details.aspx?id=29306, seit 15.8.2012
5.1
Nuget, seit 7.11.2012
5.2
Nuget, seit 17.12.2012
5.3
Nuget, seit 18.2.2013
5.4
Nuget, seit 2.4.2013
5.5
Nuget, seit 30.5.2013
5.6
NuGet, seit 16.8.2013. Diverse 5.6.x-Versionen in 2014 & 2015
5.7
Nuget, seit 20.11.2015
NamensräumeSystem.Data.Services, ab Version 3.0: Microsoft.Data.Services und Microsoft.Data.Odata
WCF Data Services werden nicht mehr weiterentwickelt "In order to give developers more control, we decided to invest in a better factored approach to building OData services using the Web API OData libraries." [https://blogs.msdn.microsoft.com/odatateam/2014/03/27/discussion-future-direction-of-wcf-data-services/]
"We do not plan to put any significant investment into adding v4-specific features to the WCF DS stack." [https://blogs.msdn.microsoft.com/odatateam/2014/03/21/announcement-odata-core-libraries-now-support-odata-v4/]
Neue Lösung: RESTier
Details zu WCF Data ServiceWCF Data Services (in Version 3.5 SP1 noch "ADO.NET Data Services", davor Codename "Astoria") ist eine Bibliothek ab .NET 3.5 Service Pack 1 zur Abfrage und Verändern einer Datenmenge (häufig eine Datenbank) über einen REST-basierten Webservice. Ab der zweiten Version (in .NET 4.0) heißt die Bibliothek WCF Data Services, was die Funktion besser trifft, denn die Data Services basieren auf auf der Kommunikationsinfratsruktur Windows Communication Foundation (WCF), haben aber keine zwingende Abhängigkeit von der Datenbankschnittstelle ADO.NET. Die Verwendung des ADO.NET Entity Frame-work als Datenmenge für einen WCF Data Service ist eine häufig verwendete und in .NET gut unterstützte Variante, aber nicht die einzige Möglichkeit.
Die Datentransportformate (JSON und ein erweitertes AtomPub) in WCF Data Services fasst Microsoft seit .NET 4.0 unter dem Namen "Object Data Protocol" (Odata) [www.odata.org] zusammen. In der Vergangen-heit sprach Microsoft hier vom „ADO.NET Data Services Protocol“.
Odata wird auch im Projekt „Dallas“ verwendet. Unter diesem Codenamen entsteht eine Aggregation zahlreicher öffentlicher Datenbanken, die ad-hoc verknüpft und über Webservices abrufbar sein sollen. Lieferanten von Odata sind zukünftig auch Berichte in SQL Server 2008 R2 Reporting Services und Listen in SharePoint 2010. Die Odata-Version in .NET 4.0 nennt Microsoft Odata 2.0.
Im Gegensatz zu klassischen Webservices, bei denen explizite Zugriffsoperationen (Lesen, Filter, Ändern, Anfügen, Löschen) für jede Datenentität in einem Objektmodell explizit definiert werden müssen, stellen WCF Data Services eine Menge von Standardoperationen zur Verfügung, die auf beliebige Objektmodelle anwendbar sind. Die Nutzung vonWCF Data Services erfolgt durch eine Serie von HTTP-Aufrufe.
WCF Data Services stellen eine Alternative zu selbstentwickelten WCF-Diensten dar. Selbstentwickelte WCF-Dienste sind flexibler, erfordern aber eine explizite Entwicklung aller gängigen Operationen (Lesen, Filter, Blättern, Sortieren, Ändern, Anfügen, Löschen, Zählen, etc.) für jede Entität. Dies kann einem sehr hohen Entwicklungsaufwand führen, wenn es viele dieser Operationen auf vielen Entitätsklassen benötigt werden. WCF Data Services stellen zur Vereinfachung generische Mechanismen für diese Operationen bereit. Währen die Produktivität klar für Data Services spricht, ist aus sicherheitstechnischen Überlegungen ist ein generischer Mechanismus, den man einschränken muss, ein größeres Risiko in Hinblick auf Pro-grammierfehler als ein normaler WCF-Dienst, bei dem man alle Operationen ausformulieren muss. Für normale WCF-Dienste spricht auch, dass es Data Service bisher nur für HTTP gibt und nur ein kleiner Teil der Kommunikationsoptionen von WCF in Data Services zur Verfügung steht.
Neben .NET-Anwendungen können als Client auch andere Programmiersprachen zum Einsatz kommen, z.B. JavaScript durch ASP.NET AJAX [http://aspnet.codeplex.com], PHP durch PHPDataServices [http://phpdataservices.codeplex.com/] und Java durch RestLess [http://blog.noelios.com/2009/09/28/restlet-2-0-m5-now-available/]. Auch nicht-Programmier können Odata-Quellen nutzen durch PowerPivot in Excel [http://www.powerpivot.com/].
Für die Verwendung in .NET gibt es seit .NET 3.5 SP1 eine komfortable Bibliothek, die die WCF Data Services-Aufrufe in Proxy-Klassen und LINQ-Operationen kapselt. Der Client kann auf diesen Proxy-Klassen Operationen ausführen, ohne dass der Server diese explizit vorgeben musste. WCF Data Services zeichnen sich durch einen hohen Grad des Automatismus aus, bieten aber zahlreiche Eingriffsmöglichkei-ten, mit denen die Entwickler auf der Serverseite die Operationen bei Bedarf einschränken können.
GeschichteVorgestellt und erster Preview auf der MIX 2007 (Codename "Astoria")
Namensvergabe: DevConnections July 2007
Zweiter Preview: Dezember 2007 (als Teil der ASP.NET 3.5 Extensions)
Erscheinen V1: zusammen mit .NET Framework 3.5 Service Pack 1 ("ADO.NET Data Services")
Erscheinen V2: Zusammen mit .NET Framework 4.0 ("WCF Data Services")
NamensgebungÜber den Namen ADO.NET Data Services konnte man streiten, da ADO.NET Data Services nichts mit ADO.NET gemein haben. WCF Data Services wäre von Anfang an ein besserer Namen gewesen.
HintergründeWCF Data Services sind unabhängig von dem Datenspeicher. Die Datenmenge wird vorgegeben durch ein Modell im ADO.NET Entity Framework (mit Zugriff auf unterschiedliche relationale Datenban-ken) oder jede anderen Menge, die durch die System.Linq.Iqueryable-Schnittstelle abgefragt werden kann.
Die Datenübertragung erfolgt via HTTP in der Representational State Transfer (REST)-Semantik. Seriali-sierungsformate sind JSON und ATOM. ADO.NET Data Services setzen technisch auf WCF auf. Ein WCFData Service ist eine erweiterte Form eines WCF-Dienstes.
Clients sind .NET-Anwendungen (Unterstützt durch Klassen im .NET-Namensraum Micro-soft.Data.WebClient) und AJAX-Anwendungen (Unterstützt durch JavaScript-Klassen im Namensraum Sys.Data). In .NET-Clients kann LINQ eingesetzt werden (LINQ-To-DataServices), wobei die Abfrage serverseitige zur Ausführung kommt.
Beispiele für Data Services-Abfragen über URLSDie URL
http://server01.IT-Visions.de/DataService.svc/Flug
ruft alle Instanzen der Klasse "Flug" ab,
während
http://server01.IT-Visions.de/DataService.svc/Flug(105)
den Flug mit der ID 105 wählt und
http://server01.IT-Visions.de/DataService.svc/Flug$filter=Abflugort eq 'Rom'
alle Flüge aus Rom.
WCF Data Services werden nicht mehr weiterentwickelt "In order to give developers more control, we decided to invest in a better factored approach to building OData services using the Web API OData libraries." [https://blogs.msdn.microsoft.com/odatateam/2014/03/27/discussion-future-direction-of-wcf-data-services/]
"We do not plan to put any significant investment into adding v4-specific features to the WCF DS stack." [https://blogs.msdn.microsoft.com/odatateam/2014/03/21/announcement-odata-core-libraries-now-support-odata-v4/]
Neue Lösung: RESTier
Details zu WCF Data ServiceWCF Data Services (in Version 3.5 SP1 noch "ADO.NET Data Services", davor Codename "Astoria") ist eine Bibliothek ab .NET 3.5 Service Pack 1 zur Abfrage und Verändern einer Datenmenge (häufig eine Datenbank) über einen REST-basierten Webservice. Ab der zweiten Version (in .NET 4.0) heißt die Bibliothek WCF Data Services, was die Funktion besser trifft, denn die Data Services basieren auf auf der Kommunikationsinfratsruktur Windows Communication Foundation (WCF), haben aber keine zwingende Abhängigkeit von der Datenbankschnittstelle ADO.NET. Die Verwendung des ADO.NET Entity Frame-work als Datenmenge für einen WCF Data Service ist eine häufig verwendete und in .NET gut unterstützte Variante, aber nicht die einzige Möglichkeit.
Die Datentransportformate (JSON und ein erweitertes AtomPub) in WCF Data Services fasst Microsoft seit .NET 4.0 unter dem Namen "Object Data Protocol" (Odata) [www.odata.org] zusammen. In der Vergangen-heit sprach Microsoft hier vom „ADO.NET Data Services Protocol“.
Odata wird auch im Projekt „Dallas“ verwendet. Unter diesem Codenamen entsteht eine Aggregation zahlreicher öffentlicher Datenbanken, die ad-hoc verknüpft und über Webservices abrufbar sein sollen. Lieferanten von Odata sind zukünftig auch Berichte in SQL Server 2008 R2 Reporting Services und Listen in SharePoint 2010. Die Odata-Version in .NET 4.0 nennt Microsoft Odata 2.0.
Im Gegensatz zu klassischen Webservices, bei denen explizite Zugriffsoperationen (Lesen, Filter, Ändern, Anfügen, Löschen) für jede Datenentität in einem Objektmodell explizit definiert werden müssen, stellen WCF Data Services eine Menge von Standardoperationen zur Verfügung, die auf beliebige Objektmodelle anwendbar sind. Die Nutzung vonWCF Data Services erfolgt durch eine Serie von HTTP-Aufrufe.
WCF Data Services stellen eine Alternative zu selbstentwickelten WCF-Diensten dar. Selbstentwickelte WCF-Dienste sind flexibler, erfordern aber eine explizite Entwicklung aller gängigen Operationen (Lesen, Filter, Blättern, Sortieren, Ändern, Anfügen, Löschen, Zählen, etc.) für jede Entität. Dies kann einem sehr hohen Entwicklungsaufwand führen, wenn es viele dieser Operationen auf vielen Entitätsklassen benötigt werden. WCF Data Services stellen zur Vereinfachung generische Mechanismen für diese Operationen bereit. Währen die Produktivität klar für Data Services spricht, ist aus sicherheitstechnischen Überlegungen ist ein generischer Mechanismus, den man einschränken muss, ein größeres Risiko in Hinblick auf Pro-grammierfehler als ein normaler WCF-Dienst, bei dem man alle Operationen ausformulieren muss. Für normale WCF-Dienste spricht auch, dass es Data Service bisher nur für HTTP gibt und nur ein kleiner Teil der Kommunikationsoptionen von WCF in Data Services zur Verfügung steht.
Neben .NET-Anwendungen können als Client auch andere Programmiersprachen zum Einsatz kommen, z.B. JavaScript durch ASP.NET AJAX [http://aspnet.codeplex.com], PHP durch PHPDataServices [http://phpdataservices.codeplex.com/] und Java durch RestLess [http://blog.noelios.com/2009/09/28/restlet-2-0-m5-now-available/]. Auch nicht-Programmier können Odata-Quellen nutzen durch PowerPivot in Excel [http://www.powerpivot.com/].
Für die Verwendung in .NET gibt es seit .NET 3.5 SP1 eine komfortable Bibliothek, die die WCF Data Services-Aufrufe in Proxy-Klassen und LINQ-Operationen kapselt. Der Client kann auf diesen Proxy-Klassen Operationen ausführen, ohne dass der Server diese explizit vorgeben musste. WCF Data Services zeichnen sich durch einen hohen Grad des Automatismus aus, bieten aber zahlreiche Eingriffsmöglichkei-ten, mit denen die Entwickler auf der Serverseite die Operationen bei Bedarf einschränken können.
GeschichteVorgestellt und erster Preview auf der MIX 2007 (Codename "Astoria")
Namensvergabe: DevConnections July 2007
Zweiter Preview: Dezember 2007 (als Teil der ASP.NET 3.5 Extensions)
Erscheinen V1: zusammen mit .NET Framework 3.5 Service Pack 1 ("ADO.NET Data Services")
Erscheinen V2: Zusammen mit .NET Framework 4.0 ("WCF Data Services")
NamensgebungÜber den Namen ADO.NET Data Services konnte man streiten, da ADO.NET Data Services nichts mit ADO.NET gemein haben. WCF Data Services wäre von Anfang an ein besserer Namen gewesen.
HintergründeWCF Data Services sind unabhängig von dem Datenspeicher. Die Datenmenge wird vorgegeben durch ein Modell im ADO.NET Entity Framework (mit Zugriff auf unterschiedliche relationale Datenban-ken) oder jede anderen Menge, die durch die System.Linq.Iqueryable-Schnittstelle abgefragt werden kann.
Die Datenübertragung erfolgt via HTTP in der Representational State Transfer (REST)-Semantik. Seriali-sierungsformate sind JSON und ATOM. ADO.NET Data Services setzen technisch auf WCF auf. Ein WCFData Service ist eine erweiterte Form eines WCF-Dienstes.
Clients sind .NET-Anwendungen (Unterstützt durch Klassen im .NET-Namensraum Micro-soft.Data.WebClient) und AJAX-Anwendungen (Unterstützt durch JavaScript-Klassen im Namensraum Sys.Data). In .NET-Clients kann LINQ eingesetzt werden (LINQ-To-DataServices), wobei die Abfrage serverseitige zur Ausführung kommt.
Beispiele für Data Services-Abfragen über URLSDie URL
http://server01.IT-Visions.de/DataService.svc/Flug
ruft alle Instanzen der Klasse "Flug" ab,
während
http://server01.IT-Visions.de/DataService.svc/Flug(105)
den Flug mit der ID 105 wählt und
http://server01.IT-Visions.de/DataService.svc/Flug$filter=Abflugort eq 'Rom'
alle Flüge aus Rom.
Die Datentransportformate (JSON und ein erweitertes AtomPub) in WCF Data Services fasst Microsoft seit .NET 4.0 unter dem Namen "Object Data Protocol" (Odata) [www.odata.org] zusammen. In der Vergangen-heit sprach Microsoft hier vom „ADO.NET Data Services Protocol“.
Odata wird auch im Projekt „Dallas“ verwendet. Unter diesem Codenamen entsteht eine Aggregation zahlreicher öffentlicher Datenbanken, die ad-hoc verknüpft und über Webservices abrufbar sein sollen. Lieferanten von Odata sind zukünftig auch Berichte in SQL Server 2008 R2 Reporting Services und Listen in SharePoint 2010. Die Odata-Version in .NET 4.0 nennt Microsoft Odata 2.0.
Im Gegensatz zu klassischen Webservices, bei denen explizite Zugriffsoperationen (Lesen, Filter, Ändern, Anfügen, Löschen) für jede Datenentität in einem Objektmodell explizit definiert werden müssen, stellen WCF Data Services eine Menge von Standardoperationen zur Verfügung, die auf beliebige Objektmodelle anwendbar sind. Die Nutzung vonWCF Data Services erfolgt durch eine Serie von HTTP-Aufrufe.
WCF Data Services stellen eine Alternative zu selbstentwickelten WCF-Diensten dar. Selbstentwickelte WCF-Dienste sind flexibler, erfordern aber eine explizite Entwicklung aller gängigen Operationen (Lesen, Filter, Blättern, Sortieren, Ändern, Anfügen, Löschen, Zählen, etc.) für jede Entität. Dies kann einem sehr hohen Entwicklungsaufwand führen, wenn es viele dieser Operationen auf vielen Entitätsklassen benötigt werden. WCF Data Services stellen zur Vereinfachung generische Mechanismen für diese Operationen bereit. Währen die Produktivität klar für Data Services spricht, ist aus sicherheitstechnischen Überlegungen ist ein generischer Mechanismus, den man einschränken muss, ein größeres Risiko in Hinblick auf Pro-grammierfehler als ein normaler WCF-Dienst, bei dem man alle Operationen ausformulieren muss. Für normale WCF-Dienste spricht auch, dass es Data Service bisher nur für HTTP gibt und nur ein kleiner Teil der Kommunikationsoptionen von WCF in Data Services zur Verfügung steht.
Neben .NET-Anwendungen können als Client auch andere Programmiersprachen zum Einsatz kommen, z.B. JavaScript durch ASP.NET AJAX [http://aspnet.codeplex.com], PHP durch PHPDataServices [http://phpdataservices.codeplex.com/] und Java durch RestLess [http://blog.noelios.com/2009/09/28/restlet-2-0-m5-now-available/]. Auch nicht-Programmier können Odata-Quellen nutzen durch PowerPivot in Excel [http://www.powerpivot.com/].
Für die Verwendung in .NET gibt es seit .NET 3.5 SP1 eine komfortable Bibliothek, die die WCF Data Services-Aufrufe in Proxy-Klassen und LINQ-Operationen kapselt. Der Client kann auf diesen Proxy-Klassen Operationen ausführen, ohne dass der Server diese explizit vorgeben musste. WCF Data Services zeichnen sich durch einen hohen Grad des Automatismus aus, bieten aber zahlreiche Eingriffsmöglichkei-ten, mit denen die Entwickler auf der Serverseite die Operationen bei Bedarf einschränken können.
GeschichteVorgestellt und erster Preview auf der MIX 2007 (Codename "Astoria")
Namensvergabe: DevConnections July 2007
Zweiter Preview: Dezember 2007 (als Teil der ASP.NET 3.5 Extensions)
Erscheinen V1: zusammen mit .NET Framework 3.5 Service Pack 1 ("ADO.NET Data Services")
Erscheinen V2: Zusammen mit .NET Framework 4.0 ("WCF Data Services")
NamensgebungÜber den Namen ADO.NET Data Services konnte man streiten, da ADO.NET Data Services nichts mit ADO.NET gemein haben. WCF Data Services wäre von Anfang an ein besserer Namen gewesen.
HintergründeWCF Data Services sind unabhängig von dem Datenspeicher. Die Datenmenge wird vorgegeben durch ein Modell im ADO.NET Entity Framework (mit Zugriff auf unterschiedliche relationale Datenban-ken) oder jede anderen Menge, die durch die System.Linq.Iqueryable-Schnittstelle abgefragt werden kann.
Die Datenübertragung erfolgt via HTTP in der Representational State Transfer (REST)-Semantik. Seriali-sierungsformate sind JSON und ATOM. ADO.NET Data Services setzen technisch auf WCF auf. Ein WCFData Service ist eine erweiterte Form eines WCF-Dienstes.
Clients sind .NET-Anwendungen (Unterstützt durch Klassen im .NET-Namensraum Micro-soft.Data.WebClient) und AJAX-Anwendungen (Unterstützt durch JavaScript-Klassen im Namensraum Sys.Data). In .NET-Clients kann LINQ eingesetzt werden (LINQ-To-DataServices), wobei die Abfrage serverseitige zur Ausführung kommt.
Beispiele für Data Services-Abfragen über URLSDie URL
http://server01.IT-Visions.de/DataService.svc/Flug
ruft alle Instanzen der Klasse "Flug" ab,
während
http://server01.IT-Visions.de/DataService.svc/Flug(105)
den Flug mit der ID 105 wählt und
http://server01.IT-Visions.de/DataService.svc/Flug$filter=Abflugort eq 'Rom'
alle Flüge aus Rom.
HintergründeWCF Data Services sind unabhängig von dem Datenspeicher. Die Datenmenge wird vorgegeben durch ein Modell im ADO.NET Entity Framework (mit Zugriff auf unterschiedliche relationale Datenban-ken) oder jede anderen Menge, die durch die System.Linq.Iqueryable-Schnittstelle abgefragt werden kann.
Die Datenübertragung erfolgt via HTTP in der Representational State Transfer (REST)-Semantik. Seriali-sierungsformate sind JSON und ATOM. ADO.NET Data Services setzen technisch auf WCF auf. Ein WCFData Service ist eine erweiterte Form eines WCF-Dienstes.
Clients sind .NET-Anwendungen (Unterstützt durch Klassen im .NET-Namensraum Micro-soft.Data.WebClient) und AJAX-Anwendungen (Unterstützt durch JavaScript-Klassen im Namensraum Sys.Data). In .NET-Clients kann LINQ eingesetzt werden (LINQ-To-DataServices), wobei die Abfrage serverseitige zur Ausführung kommt.
Beispiele für Data Services-Abfragen über URLSDie URL
http://server01.IT-Visions.de/DataService.svc/Flug
ruft alle Instanzen der Klasse "Flug" ab,
während
http://server01.IT-Visions.de/DataService.svc/Flug(105)
den Flug mit der ID 105 wählt und
http://server01.IT-Visions.de/DataService.svc/Flug$filter=Abflugort eq 'Rom'
alle Flüge aus Rom.
http://server01.IT-Visions.de/DataService.svc/Flug
ruft alle Instanzen der Klasse "Flug" ab,
während
http://server01.IT-Visions.de/DataService.svc/Flug(105)
den Flug mit der ID 105 wählt und
http://server01.IT-Visions.de/DataService.svc/Flug$filter=Abflugort eq 'Rom'
alle Flüge aus Rom.