>http://blogs.msdn.com/b/gblock/archive/2006/10/26/ten-advantages-of-an-orm.aspx
>
>And to add a few more reasons:
>- Compile time checking of types/queries.
>- Being able to apply multiple optional filters without a complicated where clause or modifying the SQL code.
>- Being able to apply an interface to multiple entities and write extension methods against that interface. For example several tables could have an active flag. You can put an IActiveEntity interface on the models for those tables and write a method such as ActiveOnly that retrieves only the active records. That same method can then be used for any set that implements that interface.

On the "without modifying the SQL code"....the reverse argument is that many tech managers are happy when a change ONLY requires a change to SQL code, as opposed to a change in some other layer.

Here's a question.

Suppose (hypothetically) I'm an I.T. manager or a manager of application development. I see one of my developers going through over a dozen technical forum posts, fiddling with syntax....while a simpler, more established and "tried and true" approach exists. I look at you, and I say (rather gruffly), "we're not here to show off the latest and greatest technology , we're here to solve problems and do it efficiently. You can show me all sorts of blog posts about an approach, but it doesn't mean a hill of beans to me if you can't use it for a pretty basic task. " What's your reply?

I'm not saying ORM and EF don't have their place. I'm just amazed when people practically go out of their way to do something (and stumble) when a far simpler approach exists in the database.