ADO .NET Entity Framework Vote of No Confidence
The signatories of this letter are unanimous in expressing concern for the welfare of software projects undertaken in the Microsoft customer community that will make use of the forthcoming ADO .NET Entity Framework.
Over the past year, Microsoft and the Entity Framework team have received a tremendous amount of feedback from experts in entity-based applications and software architectures on the .NET platform. While Microsoft’s announcement of its intention to provide framework support for entity architectures was received with enthusiasm, the Entity Framework itself has consistently proved to be cause for significant concern.
We remain willing to collaborate with Microsoft and the ADO .NET Entity Framework team to forge a positive action plan to help the Microsoft customer community achieve success with entity architecture applications. We want to see entity-oriented applications continue to succeed on the .NET platform. We are committed to working with Microsoft to share our considerable experience with entity architectures, and approaches, as well as our successes and failures with the Entity Framework team with the hope of ensuring successful execution of entity-oriented projects within the Microsoft customer community.
We want the Entity Framework to be a first-rate product of the highest quality, and a tool that exceeds expectations and empowers customers and developers to create sustainable and maintainable software architectures that can withstand the pressures of software development projects of any significant size, complexity, or schedule compression.
We recognize that the Entity Framework’s momentum toward its planned release this summer isn’t likely to be slowed and that there are business imperatives for Microsoft that supersede technical concerns at this time.
We collectively urge Microsoft customers to seriously consider the concerns of a group of experts that Microsoft has called, “the technical community’s best and brightest,” and who share a deep commitment to community and a willingness to help others. We have been building entity-based applications since the initial release of .NET using both Microsoft and non-Microsoft tools, and have accumulated a tremendous amount of experience in general best practices for entity-based applications as well as best practices for entity-based applications with .NET.
Because of the technical misgivings with the Entity Framework’s current design and implementation, and the potential future risk they pose to Microsoft customer projects we respectfully submit a Vote of No Confidence for the ADO .NET Entity Framework in its current state and for the on-going challenges with the expert community feedback processes.
We urge Microsoft customers who will be considering entity architectures for their software application projects to be aware of the following unresolved issues with the impending first release of the ADO .NET Entity Framework:
INORDINATE FOCUS THE DATA ASPECT OF ENTITIES LEADS TO DEGRADED ENTITY ARCHITECTURES:
While entities are data objects from the perspective of data storage and data storage technologies, entities are more significantly behavioral objects from the perspective of entity-oriented applications.
The Entity Framework’s focus is on the support the data storage aspects of entity objects at the expense of the primary use case for entities in software applications, which is to govern business rules and business logic. Without recognizing this key architectural enabler and distinction, the ADO .NET Entity Framework team has built only half of the story into the framework, and has over-produced the features and functionality for the aspect of the framework that a data storage product team might be predisposed to.
Creating a data access framework for entity architectures means that the framework must not force entity objects in software to become merely data objects. A data access framework for entities must respect the inherent qualities of software entities while still allowing them to be transformed into data entities when they are stored. The entity objects must be allowed to diverge from the data structure without friction. While the Entity Framework does allow for this variance, the Entity Framework is not optimized for this scenario.
An entity framework must be built to support both the behavior as well as the data storage aspects of entity architectures. Contrary to the workflow implied by the ADO .NET Entity Framework, software entities should be built around behavior first rather than data.
EXCESS CODE NEEDED TO DEAL WITH LACK OF LAZY LOADING:
Lazy loading is an essential capability of a data access framework for entity-based applications. Without lazy loading, an entity-based application’s codebase will need to include unnecessary prescriptive data loading procedures for every possible business scenario in which the business entities will be used.
The many permutations of procedural script code required for loading entities for similar situations causes either unnecessary complexity that results from trying to reuse similar code, or unnecessary bloat resulting from duplication of data access client code.
The business logic of an entity-based app that is not empowered by lazy loading becomes polluted with data access code, causing this the core business logic to be obscured by this excess data access code, and increasing the cost of incorporating changes into the application, and in maintaining the application.
SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE BEST PRACTICES:
Shared and canonical data models were once thought of as an ideal solution to entity dissonance problems. Canonical models proved to be more costly to use in practice.
The hypotheses that once supported the pursuit of canonical data models didn’t and couldn’t include factors that would be discovered once the idea was put into practice. We have found, through years of trial and error, that using separate models for each individual context in which a canonical data model might be used is the least complex approach, is the least costly approach, and the one that leads to greater maintainability and extensibility of the applications and endpoints using contextual models, and it’s an approach that doesn’t encourage the software entropy that canonical models do.
The failure-prone canonical model approach wasn’t difficult for a lack of elaborate tooling along the lines of the Entity Framework. The essential problem resides in the assumption that a canonical shared model provides the benefits in practice that it should theoretically enable.
While some of the theoretical benefits of canonical models can be realized, the architectures around canonical data models tend to suffer significantly, causing software organizations to trade off much more powerful advantages merely to adopt canonical models.
Ignoring the inherent weaknesses in canonical model approaches and promoting these approaches to the Microsoft customer community ignores the advances in knowledge, understanding, and practice made in technical architecture for entity applications and exposes Microsoft customers to unnecessary risk.
LACK OF PERSISTENCE IGNORANCE CAUSES BUSINESS LOGIC TO BE HARDER TO READ, WRITE, AND MODIFY, CAUSING DEVELOPMENT AND MAINTENANCE COSTS TO INCREASE AT AN EXAGGERATED RATE:
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.
The tight coupling between the shape of the data structure and the business domain impairs a team’s ability to accurately model the behavioral logic of a system. The conceptual model mapping doesn’t improve this situation.
The tight coupling of the persistence infrastructure to the entity classes largely eliminates the ability to efficiently use very tight feedback cycles on the business logic with automated testing. In its current state, EF entity classes cannot be effectively unit tested independently of the database.
The efficiency of automated unit testing of behavioral objects is largely a matter of how easy the mechanics of test data setup are and how quickly the tests can be executed. Using the actual database will make test data setup more laborious, introduce data to satisfy relational constraints that are not germane to the test, and make test execution an order of magnitude slower.
A team’s ability to do evolutionary design and incremental delivery is damaged by the Entity Framework’s inattention to fundamental software design principles like Separation of Concerns.
EXCESSIVE MERGE CONFLICTS WITH SOURCE CONTROL IN TEAM ENVIRONMENTS:
When the Entity Framework is used on projects staffed with more than one developer, merge conflicts occur whenever two developers make changes to an entity diagram. Since the diagram tool is the default and intended tool for making changes to an entity model, the frequency of this problem is will result in an unacceptable level of friction in team member interaction and change integration.
This problem occurs because the file format used for saving the entity model contains both visualization elements and the entity model itself. The resulting merge conflicts require merging by hand to avoid corrupting the entity model, as these conflicts are too drastic to be automated by the merge resolution built into modern source control systems.
