Entity Framework Has Layers Like an Onion
If you’ve been following my tweets, you’ll know that I’ve been experimenting with Entity Framework lately. I’ve been digging around, looking at the generated code for EF and realized something very interesting.
[EdmEntityType(NamespaceName="DBO", Name="Project")]
[Attribute(IsReference=true)]
[Serializable()]
public partial class Project : EntityObject
{
You see that? My entity has Attributes on it…very similar to NHibernate attributes. Here’s another interesting tidbit from a property that exposes a relationship between two entities (a so-called Navigation Property)
[EdmRelationshipNavigationProperty(
"DBO", "FK_tblTasks_tblProjects", "tblTasks")]
public EntityCollection<Task> Tasks{
get{
return RelationshipManager.GetRelatedCollection<Task>(
"DBO.FK_tblTasks_tblProjects", "tblTasks");
}
set{
if ((value != null)){
RelationshipManager.InitializeRelatedCollection<Task>(
"DBO.FK_tblTasks_tblProjects", "tblTasks", value);
}
}
Notice that the navigation property has an attribute giving the name of the relationship (here the same name as the foreign key) and the related entity name (again given the same name as the foreign table). Behind the scenes it uses a relationship manager (property of EntityObject) to get/set the values.
So What’s Your Point?
The point is that the generated code is nothing more than a strongly typed convenience layer over the EF API. The point is that it is possible to provide your own engine that lays over this API and removes the coupling to EntityObject from your Domain Objects. The core of Entity Framework…the database abstraction layer…is very solid. It’s begging to have a proper O/RM engine placed on top of it.