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

Dr Herbie
Half the population have below average IQ

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

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

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

In reply to fuzzylintman

#Aug 17th @ 9:31 PM

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.