I’ve been looking at a couple of the new technologies that were released with .Net 3.5 SP1, mainly the Entity Framework (EF), and ADO.Net Data Services ADNS). I happen to look at ADO.Net Data Services first, and it seemed to look pretty good on paper. There was a reference to the Entity Framework in that Data Services uses the Entity Model (EM) from EF to provide the data access layer.

Last night I started searching for more information on the Entity Framework, and instead of finding examples, best practices, etc, I found a battle waging between the Creators/Supports of the Entity Framework and people practicing what I have come to know as Alt.Net.

I am using the term Alt.Net to refer to ideas and concepts such as Domain Driven Design (DDD), Test Driven Development (TDD), Agile, Plain Old CLR Objects (POCO), Persistence Ignorance (PI), and nHibernate (as there is allot of comparison made to the EF). I should also note that the ideas and concepts listed are not entirely specific to .Net, nor is this a complete list. Furthermore, you could be a practitioner of Alt.Net and completely support EF.

To get an idea of where the Alt.Net crowd is coming from you should start off by reading the Vote of No Confidence on WuFoo. Then simply Google for Entity Framework and you will see all sorts of competing opinions. Frans Bouma, creator of LLBLGen Pro, has a couple of posts (here, and here) that I think show he is against the EF, but for slightly difference reasons then the Alt.Net crowd. Here are some of the top Pros and Cons I’ve found.

Pros:

1. It’s support by Microsoft, and as such, will gather much momentum and community support
2. It’s good enough for X% (usually stated as greater then 50%) of software projects out there.
3. GUI editor/mapper makes it easier to use then other ORM tools like nHibernate
4. EF is part of a larger push by Microsoft to provide technologies that focus on an Entity Model (See Ado.Net Data Services)

Cons:

1. No support for POCO’s and Persistent Ignorance
2. Hard (or impossible) to develop using a Domain Driven Design, or Test Driven Design methodology
3. Single model/mapping file introduces merge conflicts in a source control environment
4. No additional functionality of products like nHibernate

I kind of see Pro #1 being the cornerstone to the argument. I feel that the Alt.Net crowd knows that EF has a good chance to become the defacto standard, and that they will be forced by their clients and employers to use it. As such, they are trying to point out some of it’s short comings to Microsoft in hopes that if it does become the defacto standard, that it won’t suck (to them) as much.

The EF team has been very open with the community, and reading posts leading up to the release of the EF, you can already see that the team was listening to the community. They introduced something called IPOCO, which removed the requirement that Entity classes implement a base class, and instead implement interfaces. This pleased some, while it annoyed others, since it still breaks true Persistent Ignorance.  I feel it’s a step in the right direction.

There are other indications that V2 of the EF will introduce true Persistant Ignorance, although the EF team usually talks about a performance hit (and it sounds like it could be a big performance hit) if you want to go the POCO route. The reason for this is the lack of the EntityKey field in a POCO object, which is used in subsequent operations after an entity is retrieved from the framework.

Overall, I find myself smack dab in the middle of the two camps. I’ve been trying to explore and learn more about Alt.Net, while at the same time keeping up on the latest from Microsoft. I’ve come up with the following guidelines for myself.

1. Since EF is not support in Compact Framework, and I need to write business entities for the Compact Framework, or one’s that can be used in both the Full and Compact Frameworks, EF is out (so is nHibernate for that matter).
2. If I need to work on a new back end application that is going to be using SQL server exclusively (there is support for other data stores in EF), then EF might not be a bad way to go.
3. If I need to work on an existing back end application, I don’t think it’s worth the time to switch to EF yet, as it’s still a V1 product.

In the near term, I see my self doing some CF programming, as well as some one-off programming against our backend, which gives me a nice blend I guess. I’ll get to play around with EF some, and keep exploring the ideas of Alt.Net.

One final item I’d like to point out is the Entity Framework Contrib Project on CodePlex. While it hasn’t had a release since before RTM of the EF, it does provide some very interesting additions to the EF. The one that interests me the most, might just in fact be the bridge between the EF and POCO that everyone is looking for. Using PostSharp, the IPOCO interfaces are implemented at compile time, thus keeping your entities persistent Ignorant. The trade off is that you have to add some attributes to your code, but at least you could add these conditionally, which would help with the CF/FF issues I have.

Unfortunately the main contributor has taken a job and Microsoft on the SilverLight team, and in response to the EF’s team to add POCO support, has lost some of his interest in the project. I really like the post compile time option that the contrib project uses, as it seems to address the performance hit that the EF team says their POCO solution will have.