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.

[edit: modified text slightly to more accurately reflect my point and remove references to Julia being fooled, which apparently has been interpreted as Julia being a fool. Apologies.]

I'm off to bed, but thought I'd end up the day on a note. There are many flaws in the programming model adopted by the Entity Framework and they've been documented enough. But this is not what makes me cringe the most.

The Entity Framework team responds to the vote of no confidence by proposing fixes to programming issues in v2, talks of openness in the design of the next version, and have got people thinking that we object with the programming model. They even suggest that it's alright for Microsoft to deliver a tool that violates best practices established by people that built real systems.

[edit: I don't believe this is done with malicious intent, but I do believe there is a fundamental misunderstanding of the arguments that have been put forward, both by the EF team and their supporters and by the signatories of the letter]

The idea that a conceptual model can represent everything for everyone through designer-generated angle-bracket files is the issue. The fundamental of selling your product as one model crossing tiers and being standardized to all is a sweet dream that will end up biting anyone getting in contact with such a system. When Microsoft says transparently, I hear painfully.

The EF team explain how to fix the syntactic sugar without addressing the elephant flaw in the model is equivalent to telling people disagreeing with the one conceptual model to rule them all that they're just nitpicking over syntax. It's quite amazing that the people voicing their anxiety at the ripple-effect of introducing EF are being discarded as a small minority of weirdos that shouldn't complain because their way is not being adopted until v2. The reality is that a majority of those people are leading the industry in interesting directions discovered through experience and reflection, and their ripple effect is wide. . There is no wonder why TDD and BDD (and DDD and DDDD and all those acronyms I hate so much because of their opacity) all started with a couple of people, not with a couple of tools and designers.

Microsoft has a responsibility, because of its size, to not screw the people that are trying to promote a better craft. When those people react to a technology like they have with the Entity Framework, they should be listened to, because by delivering yet another monster (sharepoint anyone?), Microsoft may generate business but in the process degrade the overall quality of their development ecosphere. In the long term that may just end-up killing them, as the market will decide on better, simpler and more efficient tools. It's the law of two feets. But this movement takes years and impacts everyone that has to maintain a system.

As for Entities, they exist as several transpositions adapted to not only the programming model but also the context in which you use them. My notion of a user and your notion of a user only share a couple of trivial rules. If you ever, ever try to come up with one model that covers everything, you'll be too flexible or not enough, and your project, and the projects depending on your project, will fail. Full stop. It's been tried and tested. It is wrong. Like putting mustard in your corn flakes.

[updated for clarity and minor adjustments]

Picture worth a thousand bibles.