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

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

Follow the Discussion

Follow
Oops, something didn't work.

Try again?

Sign In to be begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to this comments

Dr Herbie Horses for courses

Jul 27, 2008 at 10:45 AM

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
mtaulty Mike Taulty

Jul 29, 2008 at 4:11 PM

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.
fuzzylintman

Aug 17, 2008 at 9:31 PM

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
mtaulty Mike Taulty

Aug 20, 2008 at 11:47 AM

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.