The criticism of the Entity Framework is not just around Domain Driven Design

Some of the response to the open letter on the Entity Framework have suggested that the criticism comes from practitioners of Domain Driven Design, as outlined by Eric Evans, who find that the model proposed for Entity Framework does not gel with their objectives. This is a mis-characterization of what is happening here. Eric has a number of insights in Domain Driven Design related to ideas like ubiquitous language but many of the ideas in conflict which have existed in the OO community for a long period of time outside of that context.

As an example the idea of persistence ignorance, or separation of concerns. In September 2000, in response to the complexities of the Enterpsise Java Bean (EJB) model, Martin Fowler, Rebecca Parsons and Josh MacKenzie started the POJO or Plain Old Java Project which highlighted the benefits of coding business logic into regular java objects over beans. EJBs were an ambitious attempt to support persistence, transactions, events, rpc etc in a single component. While there was an initial rush to adoption, they quickly proved a millstone around the Java communities neck, because of their complexity. Technologies like Spring and Hibernate emerged as less-complex ways of delivering enterprise class solutions, many of them were later to be incorporated into drastically revised EJB visions.

The .NET community had a huge amount to gain from this experience. Ports of Hibernate and Spring offered the community the chance to avoid the mistakes of the past. However, seemingly unaware of the lessons of history the EF team embarked on a project to produce a complex framework, of which persistence is just one aspect, reminiscent of the EJB initiative. So the reaction against the EF comes from its failure to learn lessons that another community has struggled with around complexity and ambition.

So the warnings issued around the EF are trying to prevent .NET developers straying into the same path of pain that their Java brethren experienced with complex non-PI frameworks.

As another example let us consider the notion of designing your system by focusing on objects instead of data. This one is pretty old. At OOPSLA in ’89 Kent Beck and Ward Cunningham presented a paper on using CRC cards as a technique for teaching object oriented thinking. They wanted to find a new guide for procedural programmers used to designing systems by thinking of processes, data flows and data stores by an equivalent tri-partite model for the OO world. Their answer was class names, responsibilities, and collaborators. Even this far back Kent and Ward urge their audience to “[create] objects not
to meet mythical future needs, but only under the
demands of the moment”. Even this far back (and perhaps even further, this is just an example I was aware of) the focus on building an OO system by modelling classes, their responsibilities, and collaborators and not processes, data flows, and data stores was being espoused as good OO practice. This ‘domain’ focus is not a new ‘fad’ but pretty much how you do OO design as opposed to procedural design. It would not seem sensible to do OO by modelling processes, data flows and data stores and then generating an OO design from them, but this seems to be the approach that the EF takes. This makes it overly-complex to adopt an OO approach using the entity framework.

So these concerns are not because of some new ‘faddish’ method favoured by the community.


About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group.
This entry was posted in Object-Orientation. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • nihala

    I found this post with a different look at the frameworks in use today. Although Spring/Hibernate are better than what we had, does that actually mean appropriate for most of the software we write?

  • alissaearl

    country uncertainty economists process adaptation

  • elvinakeen

    permafrost infrared turn alone yahoo release browsers atmosphere

  • Pharmc61

    Very nice site!

  • macikass

    conclude debate satellite resulting related late

  • Pharmk497

    Very nice site!

  • http://link name


  • JoeW

    I don’t think saying that something is OO is enough of a defense. You can have OO behind those state objects and your service model can contain a lot of transient state and a lot of OO.
    What you get with a separation of state of behavior is less complex systems. I’ve inherited far too many complex OO systems with deep hierarchies to go down that road again.

  • Jeremy Gray

    @JoeW (and Andrey Shchekin, to a lesser degree)

    re: “You can still have a simplistic design with your business logic in services and your OO model as simple state holders.”

    “business logic in services” == procedural programming / “transaction script”

    Necessary at times (eg. for collaborations that for some reason cannot be hidden within an aggregate), but not desirable.

    “simple state holders” == !OO

    simple state holders are !OO. They are structures. Nothing else to add to this one.

  • Andrey Shchekin


    I agree with what you say, too much behavior in entities _is_ a problem in my experience. IN the case I prefer, they are not DTO, but still most of functionality lives in IoCed services with their own inheritance and behavior.

  • Ian Cooper


    I do not think we were expecting them to innovate. But I think we were hoping they would reflect current ‘best-of-breed’.

  • Logicalmind


    I think the problem is that MS is reproducing the overly complex over-engineered solutions that burned the Java camp 8-10 years ago. There has been an evolution in the Java world towards better solutions. Many smart people have spent years producing very useful frameworks. Rather than MS standing on the shoulders of these giants, they feel that they must be the giants for others to stand on. Sometimes it works, and sometimes it doesn’t.

    As a recent convert to C#/.NET from Java, I generally find my long-time C# co-workers to be unkind to technologies not produced by MS. I’ve been working hard to open their eyes to open source projects for .NET ( for example) that are very good solutions. It has been tough going…

  • Mike Stockdale

    Well said. The Java world has been often burned by overly complex and over-engineered solutions. We don’t need to repeat that in the .NET world. It’s not just about blindly following Java, let’s innovate, but without ignoring the lessons of the past.

  • Meisinger

    I for one think that the .Net community needs to go through some trials and tribulations to understand what you are talking about.

    In my mind there are just some things that we shouldn’t be protecting the every day developer from. If [those who sit high on a mountain] tell me that something is a bad idea or I shouldn’t use a certain technology then I would ask why?

    If the only answer is because in the past, in another language, on a different platform there was a similar issue then what have I learned? How have I grown as a developer?

    Why can’t I go and try it out for myself and oh… I don’t know… learn how bad it is and grow from that experience?

    Don’t we also gain innovation through poor implementations? If I understand you correctly… Hibernate and Spring are two great pieces of technology that came out of a poor EJB implementation. Don’t we want to grow in a similar fashion in the .Net world? Or should we simply look to Java, Ruby, Haskell for all of our technologies?

  • Ian Cooper


    It is the complexity that is at issue. The POJO movement was concerned with the complexity of EJB. The concern around PI with EF is around complexity.

    Those that do not understand the lessons of history are condemned to repeat its mistakes.

    Anemic Domain Models are a separate, if important, issue

  • Bryan Reynolds

    I think everyone was thinking or hoping that Microsoft was going to inovate here, where they are just catching up. Wait for version 3.

  • JoeW

    I still don’t buy Fowler’s assertion that the “anemic domain model” is an anti-pattern. EJB failed for a number of reasons, mainly for its complexity. But I wouldn’t muddle the two arguments. You can still have a simplistic design with your business logic in services and your OO model as simple state holders.

  • Chris Patterson

    Thanks for taking the time to spell out the real issue.

    For some reason, the .NET community driven by Microsoft seems to be completely ignoring the history that the Java community has already experienced. Microsoft should take this as a time to try and learn from the failures of similar approaches in the Java world and adapt to try and be a leader towards more pragmatic approaches to development.

  • Tobin Harris

    Nice post, and some good links too. Will be interesting to hear how MS justify their decisions.