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 alt.net community.
Posted
Thu, Jun 26 2008 11:46 AM
by
Ian Cooper