Ovenstående typenavne og begreber har jeg det nødvendigvis ikke specielt svært med. Navnene er jo gode nok, men jeg synes dog de forvirrer mig og omverdenen når der skal gøre brug af dem.
Hvad er en DataService og hvad kan den ?
Med .NET 3.5 rammeværket kom der en ny ting i forbindelse med det alle har snakket om så længe. En REST service. ADO.NET Data Services er et fuldstændig hul-i-hovedet navn, men det er det trods alt blevet navngivet. En DataService og en ADO.NET Data Service er altså det samme, herfra kalder vi det en DataService. Og hvis jeg ikke vidste bedre, så ville jeg tro at min kollega, René Løhde havde opfundet begrebet REST, for det er virklig kommet ud af hans mund en del gange.
Det som en DataService skal bruges til er, at læse data. Data der kommer fra en vilkårlig kilde, om det er en database, en xml fil, en collection eller noget helt andet er fuldstændigt ligemeget. Man kan også godt begynde at gemme data igennem en DataService, men OB spiller heller ikke i jakkesæt vel ? Se på brugen af en DataService som et lag i en lagkage:

Når du har lagt dit DataService lagkage lag ovenpå dit data lagekage lag, så kan du begynde at forspørge op imod de data, og det gøres ved hjælp af REST og…hold nu fast…en DataServiceContext.
DataServiceContext er til klienten
Hvis du gerne vil snakke med en DataService så har du mulighed for at gøre det ved hjælp af en DataServiceContext. Hvis du holder dig indenfor .NET rammeværket bør du sjældent selv implementere en DataServiceContext, men f.eks med Azure table storage er du nødt til det. Du tilføjer ganske simpelt bare en “service reference” indefra det strålende udviklingsværktøj ved navn Visual Studio og peger den på den DataService du gerne vil snakke med. Nu har du lige pludselig en fået et lag mere i din lagkage.

Det sexede ved både DataService og DataServiceContext typerne er at du ikke rigtig lægger mærke til dem med når du arbejder med dem, de gør bare det de skal. Som jeg nævnte tidligere så synes jeg kun en DataService skal bruges til at læse fra.
DataContext er hvad du får…
…når du arbejder med en af Microsofts OR/M’er. Så om du bruger LINQ 2 SQL eller Entity Frameworket, så ender altid ud med en DataContext i bunden.
Du kan pege din DataService på din REST enable din DataContext
http://msdn.microsoft.com/en-us/data/cc745957.aspx
Du kan pege din DataService på en collection af ikke-relationelle data
http://blogs.msdn.com/wriju/archive/2009/03/07/ado-net-data-services-non-relational-data.aspx
ADO.NET DataService skulle have været en binding i WCF stakken
Det er ikke alle der kender forskellen mellem en WCF service, ASMX service og nu en DataService, og derfor skulle istedet for at skabe mere forvirring med et nyt rammeværk, have lavet en DataService som en ny binding i WCF. Det samme gør sig gældende med ASMX webservices. Husk ligeledes at en DataService returnere specifikke ADO.NET typer.