This blog has, IMO, some great resources. Unfortunately, some of those resources are becoming less relevant. I'm still blogging, learning tech and helping others...please find me at my new home on http://www.jameschambers.com/.

Friday, August 21, 2009

Where did .Add go?

I decided to make the very powerful shift from Linq to SQL to the Entity Framework for a spike solution I am working on.  I had been exploring it for some time but hadn’t really gotten into a nuts-and-bolts project with it.

Everything is an entity.  If you’ve worked with ORMs before you’ll get this concept easily.  A collection of entities is called an entity set.

Some entities are related to other entities; as in, each order has a customer related to it, and each customer has zero or more orders related to it.

You create an instance of your data context and then you have access to all your entity sets.

I had expected, because of other familiar frameworks that I would be able to do context.Orders.Add(newOrder), but this is not the case.

Multiple entity sets can be created with the same base entity type.  So, if you have an order entity, you can have an entity set for ActiveOrders and one for ClosedOrders (etc.). 

I haven’t had a chance to dig too far into the full reasons, but this did result in a change to some of the context naming, positioning and structure of the base classes.

So, where did the Add method go?  It’s still there, it just doesn’t live in the context entity sets.  The context now has strongly typed methods (which are also strongly named) that allow you to add that one base entity to whichever entity set you need.  The new name is context.AddToEntitySetName.

Also, if you have related entities you can still do the old customer.Orders.Add(order) call.

I realize there are complications but, and again, without having gotten too far into it, I would like to know why the entity set – which is strongly typed – can’t have it’s own add method too?

No comments:

Post a Comment