Choosing an API to Talk to the Entity Framework
Diego Vega started me thinking about the differences between the different API's to the Entity Framework. I am currently doing a lot of writing about the Entity Framework and preparing many sessions on the topic so it obviously interests me :). I had asked Diego about some of the differences between Entity SQL and using the strongly typed syntax of LINQ. He posted a quick list of some of the differences and similarities in this post today. (Thanks Diego)
That's a nice hit list of differences. I had not thought about how you can navigate with Entity SQL even without a Navigation property. Going further on this train of thought I figured I would post my interpretation of a similar question I get from people a lot.
In what situations would I choose 1 over the other?
The options being:
- Entity SQL with Entity Client
- Entity SQL with Object Services
- LINQ with Object Services
- Entity SQL with Entity Client
- when you need to read data and not write to it
- when you need dynamic queries
- Entity SQL with Object Services
- when you need to retrieve entities you can interact with and persist, using a dynamic query
- LINQ with Object Services
- when you need to retrieve entities you can interact with and persist, using strongly typed syntax
I intentionally left this post very short as a means to help those who are just trying to wade through the deluge of information that is available on the Entity Framework. My general style is to keep blog posts to a quick and easily digestible piece of information. Deep dark details of topics I usually reserve for articles as I know personally when I read a blog post that goes on and on I start to lose focus ... which means I have a short attention span :)
This is obviously an involved question/answer as the situation has to take into account several factors to make that determination. But overall here is a high level barometer you can use: