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

Download this episode

Description

Looking at how we can built a basic .NET client against an ADO.NET Data Service

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      Dr Herbie
      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 ...


      Herbie
    • User profile image
      mtaulty
      Hi,

      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

      Thanks,

      Mike.
    • User profile image
      fuzzylintman
      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?

      -mdb
    • User profile image
      mtaulty
      Hi,

      Does using a query string like;

      /MyEntitySet?$filter=isof('MyModel.MyDerivedType')

      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?

      Mike.

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.