Linq-to-Entities and me: Does what it says on the tin

For those not reading on the web, the subtitle of my blog is the result of a lovely name-calling session by an anon on this site. Proof that it works, another person has now proclaimed that I am indeed what it says on the tin.

The same blog argues that alt.net has turned into the nHibernate mafia, and that we all have a vested interest in nHibernate and are trying to defend our territory. One of the tenets of alt.net is to be pragmatic about the tools we use, and I've delivered projects with nHibernate, activerecord and linq2sql, and will use whichever tool works for the job. I don't have dogma for one tool over the other when they deliver what I need.

And to be absolutely clear, some of my clients will eventually, for better or worse, use the Entity Framework, and I'll have to use that tooling, be it that it fits or not in my personal practices.

On a more positive note, there's been some very interesting comments to my entry. I thought I'd highlight my understanding of the discussion so far. If I've misunderstood those arguments, feel free to respond in the comments or insult me by messenger, I'm always available.

Proponents of L2E argue that this new framework has been developed to provide the same tooling for modelling your entities across your different needs: reporting, data access, etc. As such, it should be seen as a tool that lets you re-use knowledge across models. Furthermore, it should not be understood as a tool to create global entities shared across applications.

This could very well be the case, and indeed bring benefits for people using Reporting Services and other data-centric tools that are apparently a pain. But if we see L2E as a tool, then for reasons that have been highlighted previously, they won't fit my toolbox because they do not support the development model I have adopted.

That said, other people still look affectionately at the idea of a global model for your application / applications. My projects tell me those models fail and my experience shows me that a DTO approach to boundary crossing is more effective.

I have expressed concerns at the fact that L2E has been at the core of  other frameworks (like ado.net data services), because it brings the fundamental idea that the same model could be exposed as a REST service, sent over a WCF service to another windows client, and put in a can of Coke to the moon. Doing each of those things represents a completely different set of challenges, each with a different model. Maybe if LinqToEntities could fit in my toolbox, I could reuse it to model every single of those different entities I need to have for each boundary in my application. But I don't believe the power of the designer is going to solve any of my issues, and will probably introduce more.

I stay unconvinced but I'm overall happy to realize that many proponents of linq2entities have an understanding of the issues with a unique entity data model and with sharing of models.