Evolution Of The Entity Framework: Lesson 4

Tuesday, July 24, 2012

The first version of the Entity Framework could create an entity data model by reverse engineering a database, and then generating code from the resulting conceptual data model. One of the enhancements in the second release of the framework was to make the code generation extensible through T4 templates. You could download a template provided by Microsoft, customize an existing template, or create a template from scratch to tweak the code generation strategy.

EF 4 T4 Templates

T4 templates provided a nice extensibility point for teams who wanted to change the generated code. Unfortunately, one of the templates provided by Microsoft was the “POCO Entity Generator”. The POCO Entity Generator came about because many people disliked the default code generation strategy. The default strategy forced all the entities to derive from an Entity Framework base class (EntityObject), and included a large number of partial methods and serialization attributes. Many developers asked for the Entity Framework to work with POCOs (plain old C# objects) instead – but why?

Objects of Desire

The word POCO came from the word POJO (plain old Java object), a term coined around the year 2000 to describe simple Java objects that were not encumbered by framework requirements. The Manning Book “POJOs In Action” is an interesting read about why POJOs came into existence. To summarize - programmers were frustrated trying to solve business problems because the application frameworks required boilerplate infrastructure code in every class. The boilerplate code was noisy, the components were difficult to test, the software was slow to build and deploy, and the overall architecture guided developers towards implementing procedural code and transaction scripts.

POJOs were about making object-oriented development easier, because a programmer didn’t have to think about business logic, persistence, and transactions all at once. POJOs let the developers drive the software design using business requirements instead of framework requirements. In short, POJOs let the developers control the code.

My Generation

The Entity Framework POCO template technically generates plain old C# objects, because the objects don’t derive from a framework base class, and don’t include partial methods and serialization attributes. However, the true spirit of code ownership through POCOs is lost in code generation. The true spirit of POJO and POCO programming is in owning the code from the start and building a core model of the business problem to solve. Like a gardener who cares about seedlings – the developer wants to grow the classes with a hands-on approach. With EF 4, the code generator still owns the POCO classes, and the POCO template does not address one of the early criticisms against the Entity Framework expressed in the Entity Framework Vote Of No Confidence.

The Entity Framework encourages the Anemic Domain Model anti-pattern by discouraging the inclusion of business logic in the entity classes. While it is possible for the business logic to be written in partial classes, this adds some awkwardness to the code as the entity data and the entity business rules and logic live in separate knowledge and user experience contexts.

Using code generation to create a set of POCO objects is backwards, but I’ve met many teams and developers who feel good about using generated POCOs because the word “POCO” covers them in the amorphous blanket of software best practices. They don’t use test-driven development, hexagonal architectures, break away from procedural transaction scripts, or try to use any of the advantages true POCO development could provide.

The POCO template, by virtue of its name, tricked many developers into cargo cult programming.

Cargo Cult Plane

This leads us to the lesson for this entry:

Lesson 4: Understand Your Customer’s Problem

The developers who wanted to work with POCOs didn’t technically want POCOs – they wanted to own the code and build applications starting with an inner core of domain logic. Code generation couldn’t solve this problem, and the POCO template was a misleading solution.

In a future post, we’ll learn one last lesson from the evolution of the Entity Framework.

gravatar shev Tuesday, July 24, 2012
I'm following this series with interest, but I haven't figured out what you are actually saying yet. Look forward to the next installment.

It is just my opinion, but I don't agree with most of the 'vote of no confidence', aside perhaps from the lazy loading criticism. Perhaps I don't agree because there is no real explanation of the points.

Philosophically I strongly disagree with the criticism about it being data focused, as this is exactly what I want. It fits my ideal of loosely coupled software. It is almost funny that it states that EF violates 'Separation of Concerns' when it appears to be advocating such a violation.
gravatar scott Tuesday, July 24, 2012
@shev: Hopefully everything will make more sense when we look at EF 5 and contrast the differences. That might be next week.
Frans Bouma Wednesday, July 25, 2012
"The developers who wanted to work with POCOs didn’t technically want POCOs – they wanted to own the code and build applications starting with an inner core of domain logic. Code generation couldn’t solve this problem, and the POCO template was a misleading solution."

These developers simply don't understand what they're paid to do. They think they're paid to write infrastructure (entity classes, services etc.) but they're not. They're paid to solve a problem for the client. They can solve the problem for the client perfectly with code generated for them, as they can start writing the actual code they have to write right away, but instead they want to do a code generator's job by hand.

If you look closely at what you're doing when you're writing entity classes by hand, it's actually the same as what the code generator will do. What's even more funny is when you look at 'code first'. It's exactly the same as 'database first' but starting from the other side. But because the people who yelled very hard that 'code first is the only way to do it' are coders, not database people, it's suddenly ok.

Unless you start realizing that entity classes and tables both are projections of an abstract entity model, and thus represent the same thing (and thus mappings are theoretically possible to move instances of an entity definition back and forth between instances of the projections, which is the task of an ORM), you'll fall into the same trap over and over. This isn't immediately visible, but watch when a project is in progress for a longer period of time, when it has had its first revision after release (you know, the period called 'maintenance' which is the most important period of a code base because it's also the longest period of time a code base normally is in). You'll then see that modifications to entity classes or tables actually are modifications to the abstract entity model and which then are _reflected_ into the classes and / or (!) tables and thus mappings.

Just because developers write code and not table definitions doesn't make them specialists about entities, entity models, databases nor ORMs and definitely not about _how_ to deal with databases in applications. Articles like these which actually promote thinking in code and 'let the DB follow along' really don't help making people understand what they're really doing. And what they're really should be doing instead of writing infrastructure by hand. Poorly.
gravatar ross Wednesday, July 25, 2012
I've never really understood the need for pocos myself, perhaps except for a simple silo app like a blog or something.

In a serious enterprise, data is the most important thing. Applications (and their associated stacks) come and go over time, but the data will most likely exist as long as the organisation exists. Therefore data needs to be designed and treated as the most important element of a system, and the applications that hang off the data need to live with that fact.
gravatar Tudor Wednesday, July 25, 2012
The developers that wanted POCOs and code-first usually think they need something DDD-like - they want to start to implement domain classes first, with behavior and business rules, and to worry about persistence later.

They want light classes that are not tied in any way to an O/RM or persistence mechanism, classes that can be created individually as needed, using TDD, and tested in isolation without touching the DB.

Usually such developers don't want to start designing an application from the database, but from the domain (that is the center of the application), so don't see the need for any code generator. They look at the database just as a way to persist the application state, that can be optimized later if needed.

Sure, this is just an opinion, and the two camps (db-centric and domain-centric) will never reach an agreement.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!