Friday, July 10, 2009

NET Data Services + Entity Framework

I ran into an instance of pure OO zen when I decided to do Table-Per-Type inheritance and have that mapped appropriately in our model. I expose this through our ADO.NET Data Services layer and bam. We would then use data template mapping in Silverlight to map it to our control ideally.

I was excited.

Then I realized that none of this is ready for real use. It's nice, but we can't realistically use any of these things.

First off, ADO.NET Data Services does not allow a direct insert of the derived entity. I have to mess around with the ResolveName and ResolveType. Frankly, I dont know what to do. From Phani, probably the most useful person on this topic indicates that this is what's used on the client side to resolve the entity. I look at the ResolveType and pass back the derived entity. I get an error. How am I supposed to debug this? I try using reflector to hunt this down. Eventually my team lead asks me if I'm going to make my sprint and I say, no. He says that if I need to use reflector to learn how to use their API. There's a problem.

Second, derived types cannot have navigation properties. Let me repeat. This is their highly touted Entity Framework. If you cannot implement this properly then don't do it at all. Or how about not allowing the modelling to take place? I don't understand how this could happen. I didn't mind the lack fo support of enums. I like that they support a lot of different types of inheritance very well but ... it seems as though they didn't go the extra mile to make do it right.

I'll go into Silverlight but I'm tired.

I decided to make it composite. This is a place where it'll be bloated. We may include this in the next sprint to make it more OO pure.