Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

ADO.NET Data Services (VS08 Sp1 B1) - .NET Clients

18 minutes, 9 seconds


Right click “Save as…”

  • WMV (WMV Video)
Looking at how we can built a basic .NET client against an ADO.NET Data Service

Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
  • Herbie SmithDr Herbie Not dead yet.
    Can you really only link entities with that proxy.AddLink(newc "Orders", newO) syntax?  That's appalling!  Can't you just do newC.Orders.Add(newO) ?  You know, like normal OOP code would?
    Having to enter the name of a property as a string is a recipe for disaster too.  How much time is going to be spent correcting typos when code doesn't work?  It can't be a compile-time check can it, it's going to lurk there until runtime when you get an obscure error about not finding property"Order" because you forgot the 's' in the end.

    I have been holding off going to NHibernate until the entity framework finalised so I could compare them. If this is anything to go by I might just go and add the NHibernate website to my favourites because I've got a feeling I'll be spending a lot more time there ...

  • Mike Taultymtaulty Mike Taulty

    Bear in mind that;

    1) The code where we did proxy.AddLink() is nothing to do with Entity Framework at all. It is code that is generated by the ADO.NET Data Services utility "datasvcutil.exe" and can be generated for any ADO.NET Data Service from its metadata regardless of what the data source might be on the service side (e.g. custom objects, LINQ to SQL, Entity Framework and I believe someone has an implementation around NHibernate too).

    2) This is a preview. It's possible that things might change but then there are some write-ups around this elsewhere on the web and rationale behind it such as http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3674157&SiteID=1


  • This is great, but it doesn' appear to work AS well for Entity Framework when you are using inherited types (Table Per Type).  I am able to retrieve full data (including the entire derived data fields) based on the common object id (I use a Guid).  But unlike accessing the data directly (where I can specify a where clause on some of the derived class properties) it seems that I cannot achieve this when accessing the data through the service.  So for example, if my derived type has a field 'Name' then I can't query with [from c in entities.DbObject where Name == "Mike"].  Doing this directly requires (AFAIK) the use of the OfType<T> extension on the root object (in this case, 'DbObject' is the base type) but the Data Service clearly tells me that I can't use it.

    Is this accurate, or is there something that I'm missing?

  • Mike Taultymtaulty Mike Taulty

    Does using a query string like;


    help at all? I'm not sure whether using something like OfType<T> is something that's supported by the client library that you're using or not but perhaps you can acheive what you want directly through a URI?


Remove this comment

Remove this thread


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.