A vote of confidence for the Entity Framework

Keith,

There's no question that you can get things done with EF. I've tried it on a production app, and got things done.

I could not, however, be as effective as with frameworks that work well with software production approaches that allow me to deliver more value with less waste.

There are always higher levels and next levels of learning and action. Regardless of whether you've been able to use inversion of control with an ObjectContext and Repository pattern, the whole of the Entity Framework's design problem's obstructs the ability to use tightly and finely-integrated team and software practices that achieve a higher level of effectiveness.

One of the central issues that I've noticed with objections to the EF letter is a presumption that there aren't vastly better approaches to building software than those that we're already using.

If you're open to what's beyond the next gate, then getting there with a framework like the Entity Framework is going to be next to impossible. If you're satisfied with where you're at, then so be it. I've worked at a capacity and effectiveness beyond what the Entity Framework can provide, and I've observed that the biases transmitted to programmers through its design values makes it difficult to incrementally work toward moving on to radically more effective approaches.

From a Lean Production and Theory of Constraints perspective, the Entity Framework creates a bottleneck and it creates inventory. The bottleneck reduces throughput and the inventory obscures seeing and understanding. I can remove these obstructions by removing the Entity Framework, and I'm ethically obliged to do so.

One day, the Entity Framework might not be an obstruction, and I'll gladly see it work its magic in my software production efforts.

Best,
Scott

>We've settled on having a 'domain master', not a biggy for most teams?

Creating bottlenecks does have its issues. Funneling domain changes through one person can be a pain, and you lose the collective brainpower of the team with one person doing your database and entity design.

On a recent project, entities changed drastically during the beginning of the project as we incrementally found new concepts and discarded incorrect ones. It's these activities where we want to eliminate friction.

I would like to know, however, how many entities you're working with right now, and how you deal with them in the designer.

Cutting off Their Noses to Spite Their Faces
Open Letter
Dear EF Petitions,
I have read the online petition and don't know what you aim to gain from this? Complaining about whether implicit lazy loading and canonical shared models should be supported is ridiculous in a beta product. Although, your criticism was constructive creating a public forum is frankly "Cutting off your noses to spite your face ". I'm personally dismayed with the MVPs who signed, they should know better. Most of you have direct connections into the product team and can express these opinions directly to them. Why do this in public? I have a lot of friends in Microsoft not just because they are business colleagues but hard working individuals who have spent 11 hour days trying to create something unique. What if you were told your code is crap… see what I mean?
I think that you’re missing the point with the EF. Although it has issues, it’s the first issue. I would like to see of your code to see if you get it right first time.
The transparent approach announcement will prevent this type of thing happening again. If you have this press release why don’t you back down? Personal glory.. or just kicking the big guy?

Anonymous

Jimmy,
i'm working with a largel conceptual enterprise model based on the SID information model that you can find more about at http://www.tmforum.org. There are at present over 100 entity classes in there, including quite a few more domain classes which are not persisted but which are part of our core domain none theless. We did not hit any major problems with the domain master approach as much of the churn has not been reduced to a change control process on the domain itself, not every tom dick and harry should be checking this file out. I think having a couple of people charged with making co-ordinated changes to the edmx file should be sufficient for a lot of scenarios. I think also it would have been two slow with such a new technology to bring more than couple of people along this journey so quickly, particularly when you've got serious time pressures as well. The knowledge can be dispersed and handed over at a later date for sure.

The design has worked very well (particularly for a beta product). It has dealt with polymorphism, composite/atomic pattern, specification/entity patterns all with relative ease. It didn't pick these up always from the originating database (we had to work with an existing database), so most of the work was simply fixing up our domain model with the designer based on how we wanted to represent these patterns.

I would like to see the ability to add in notes and support for complex types (or components as they are called in NH) without breaking the designer, but we can wait for v2 for these

Scott,

I'm not disagreeing that NH is as an ORM more beautiful than the EF. I have worked with it from v0.6 and have used it with a passion over the last few years. The EF is architecturally flawed in several areas when held against NH. It is my opinion however that these flaws can be mitigatd to a large degree in such a way as we can take advantage of some of EF's real here and now qualities > 1. A fully supported linq implemetnation 2. Designer support 3. Extensive support across the MS stack (e.g. WCF, ASP.Net etc. etc. ). NHibernate does not offer me the comfort of things right now, and i can't with good conscience recommend it to my client as a result.

I'm therefore willing to accept the deficiencies if i have good workarounds and i am confident in the long term success of the project.

You say "There are always higher levels and next levels of learning and action. Regardless of whether you've been able to use inversion of control with an ObjectContext and Repository pattern, the whole of the Entity Framework's design problem's obstructs the ability to use tightly and finely-integrated team and software practices that achieve a higher level of effectiveness."

You'll need to much clearer here in terms of what you mean by obstruction. I think that fact that we have removed a direct dependency on the ObjectContext (and moved it to the realm of DI/IoC) is a very good thing indeed. Yes, our domain objects do reference some of System.Data.Objects.DataClasses, but we see that as a non complex refactor when v2 comes around. The calls to .IsLoaded on the EntityReference and EntityCollection outside of namespace issues that i'd be concerned about moving to v2, but nothing too major.

You say "One of the central issues that I've noticed with objections to the EF letter is a presumption that there aren't vastly better approaches to building software than those that we're already using."

Well don't count me in that group. Some may think EF is the first ORM ever made, but i'm not one of them. It could well be one of the best funded and supported though...

You say "If you're open to what's beyond the next gate, then getting there with a framework like the Entity Framework is going to be next to impossible. If you're satisfied with where you're at, then so be it. I've worked at a capacity and effectiveness beyond what the Entity Framework can provide, and I've observed that the biases transmitted to programmers through its design values makes it difficult to incrementally work toward moving on to radically more effective approaches."

Again, i need to know explicitly what you are referring to here. Developers working with a repository api have no idea they are working against the EF, we have abstracted that away. I'd like to know what you mean when you say "what's beyond the next gate". We're talking about a POCO persistence ignorant ORM system like NHibernate being the nirvana yes, or am i missing something? I'm expecting full POCO/reflection/mapping approach to be developed for v2.

My ultimate point is that, all things considered (and not just pure technical reasons) that the EF is the way to go, there are means and ways of limiting the negative impact of some the design choices in EF, particularly if you have a good working knowledge in the v2 process and where the team are headed with the design council for v2 and full persistence ignorance.

The team as far as i am aware have heard your feedback, and are integrating it into v2, what more can you ask?

Hello, I'm sure all this tech speak is very interesting but....Any chance of some new Tommy pics soon?! XXXXXXXXXXXXXXXXXXX