Entity Framework and Object/Relational Mapping
Often, people categorize Entity Framework as an Object/Relational Mapper and try to compare it to other O/R Mappers. I dare say that’s an apples-to-oranges kind of comparison. While Entity Framework does have ORM capabilities, that is only a fraction of its functionality, and more importantly, those ORM capabilities are achieved through a fundamentally different approach compared to typical O/R Mappers.
What the database world offers is the notion of persistence plus a way to statically model flat entities and relationships between entities expressed as constraints on the entities themselves. What it lacks is the ability to model runtime type hierarchies and explicit, navigatable, relationships. The object world, on the other hand, has excellent capabilities to model type hierarchies with inheritance and containment and navigatable references. But it has no notion of persistence and static modeling. Still, the object world may be considered a better option, because most of the business logic is written in object code. What O/R Mappers do is providing a mapping bridge form object- to database space. That compensates for the lack of persistence, but static modeling is still very limited.
Entity Framework takes a completely different approach – it creates a development platform in the space between database and objects. That is the Conceptual space. It’s a virtual space, unconstrained from objects- and database legacy. That allows Entity Framework to support static modeling capabilities with type hierarchies and containment as well as explicit, navigatable, relationships. What’s similar to O/R Mappers, is the mapping. However, it’s not a single, object-to-store mapping bridge, but two separate bridges – object-to-conceptual and conceptual-to-store. (The object-to-conceptual mapping is implicit for version 1.)
Entity Framework shifts the center of gravity for enterprise applications to conceptual space. That enables full-featured business domain modeling with persistence. As a result, enterprise applications can be written against conceptual models, not only against legacy databases. That further allows applications to consume data from different sources – compatible schemas in different database server brands/versions. Some applications may perform tasks over models alone, without any data consumption, e.g. higher-level programming languages and frameworks.
The role of the ORM capabilities in Entity Framework is to provide applications with seamless access to conceptual space. It’s even possible that third-party object-level development platforms may implement their own mapping bridges to Entity Framework conceptual models in future. (That doesn’t mean that Entity Framework will not continue enhancing its object-level support.)
To close on the loop – Entity Framework is much bigger than a mere O/R Mapper. It is a conceptual-level development platform, and its ORM capabilities are an interface for applications to interact with conceptual models.
For more information on Entity Framework, visit the ADO.NET team blog at: https://blogs.msdn.com/adonet.
Information on downloading Entity Framework Beta 3 is available at this blog post: https://blogs.msdn.com/esql/archive/2007/12/06/EntityFramework_5F00_Beta3.aspx
Comments
Anonymous
January 08, 2008
Hey Now Zlatko, Nice Post very inofrmative. Thx 4 the info, CattoAnonymous
May 30, 2008
Often, people categorize Entity Framework as an Object/Relational Mapper and try to compare it to other O/R Mappers. I dare say that’s an apples-to-oranges kind of comparison. While Entity Framework does have ORM capabilities, that is only a fractionAnonymous
June 05, 2008
Often, people categorize Entity Framework as an Object/Relational Mapper and try to compare it to other O/R Mappers. I dare say that’s an apples-to-oranges kind of comparison. While Entity Framework does have ORM capabilities, that is only a fraction