Geeks With Blogs
Chris Falter .NET Design and Best Practices

Our shop has been looking for a way to simplify the interaction between our domain layer and data layer.  The data layer uses typed datasets for all its operations.  When it retrieves data, it populates a dataset; when it stores data, it checks the DataRowState of all rows in the dataset, and calls the appropriate stored procedure to insert, update, or delete the data.  The domain layer then uses dataset elements as the in-memory backing store for properties and collections.  A collection typically uses a DataTable, for example, and a collection member would use a DataRow in the DataTable.

This arrangement has some advantages:

  • Between requests, domain objects can cache their state in session by caching a dataset.
  • DataRowState can inform the logic about which CRUD operation to perform on a DataRow.  Unmodified data can also be skipped over, yielding improved efficiency.
  • We have considerable freedom in designing domain classes.  We can make a property read-only, for example, if it corresponds to an immutable database field, such as an identity column.

This arrangement also has a big disadvantage, however.  We end up with lots of properties that look like this:

public string Phone
get { return dr.PHONE; }
set { dr.PHONE = value; }

This property's one and only use is to map a domain attribute (an entity's phone number) to a particular field in a DataRow (dr).  Our domain layer has hundreds of these pass-through properties, which are a very verbose and not especially readable way of mapping between the domain and data layers.  So we've been looking for a better way to handle this mapping.

Along comes the .NET Entity Framework (EF), which provides a tool that creates a domain-to-data map in XML format.  Our first reaction was: this is just what the doctor ordered!  And supported by Microsoft, to boot. 

On closer examination, though, the EF toolset has some growing up to do before we could consider using it in our web applications.  It can generate only public get/set accessors in the entity domain model (EDM) classes, for example.  You cannot make a property read-only, or internal/protected/private, or virtual.  You cannot map a non-generated property to a database field.  And programming in a straitjacket was not what we had in mind for a new approach.

Second, EDM classes generated by EF do not have any supported way to cache their state.  A Microsoftie is working on a tool ("Perseus") that can serialize the state of an entity using an EntityBag<T> instance, but it seems somewhat incomplete (and definitely not supported) at the moment.  Since our web apps do cache domain entity state, adopting the EF right now would entail an important risk.

What alternatives exist?  We can license DevForce EF, which is built on top of the EF and seems to offer pretty much everything that it lacks.  Or we can try NHibernate, an open-source .NET port of the Hibernate tool which is quite popular in the Java development world.

Or maybe we can just wait for the EF to mature.  Microsoft has big plans for the EF, and intends to make REST-oriented web services, Reporting Services, workflows, etc. EDM-aware.  So an EF investment today can yield important dividends in the future.

Even though I cannot render a definitive answer, I hope that this discussion will help readers make an informed discussion about their ORM choices in the .NET world.  What do you think?  Leave a comment with your insights or questions!

Posted on Tuesday, May 27, 2008 9:50 AM Database Considerations , Software Architecture | Back to top

Comments on this post: .NET Entity Framework: Is It Ready for Web Prime-Time?

# re: .NET Entity Framework: Is It Ready for Web Prime-Time?
Requesting Gravatar...
Hey Chris

This doesn't address all of the issues, but I did want to point out that with the latest iteration of EF (in the VS2008 SP1 bits), the focus of your first point has changed.

You can mark the Getter and Setter for an entity Public or Internal.
You can mark the Getter & Setter for individual properties (scalar & Navigation) as Public , Internal, Private or Protected.
And you can mark an EntitySet's Getter Public or Internal.

WRT to state - yah - IdeaBlade looks to have done a good job with this and hopefully there will be more patterns coming from developers as people dig in and figure things out. Take a look at PostSharp4EF on Codeplex/efcontrib for some ideas. For simpler web apps there is the EntityDataSource now which persists original values in viewstate so that it can perform updates. Now that EF is part of the VS product lifecycle, it's hard to know if we'll get (that's supported) between now and
Left by Julie Lerman on May 29, 2008 1:36 AM

# re: .NET Entity Framework: Is It Ready for Web Prime-Time?
Requesting Gravatar...
oops - rephrase!
Entity doesn't have getter & setter (DUH - I need my coffee) . I mean to say that entity has an ACCESS property that can be public or internal.

Left by Julie Lerman on May 29, 2008 1:48 AM

# re: .NET Entity Framework: Is It Ready for Web Prime-Time?
Requesting Gravatar...
@Julie - Thanks for dropping by and bringing some fresh data with you!

One of my goals would be to cache the current state of a business object without having to bind it to a control. I wonder if there's a way to use the EntityDataSource to cache an business object graph in ASP.NET Session. Maybe using SavePageStateToPersistenceMedium would work?! Or maybe a book writer like you could come up with something more elegant? :)
Left by Chris Falter on May 29, 2008 9:24 AM

# re: .NET Entity Framework: Is It Ready for Web Prime-Time?
Requesting Gravatar...
For readers interested in the details of setting access modifiers on EDM elements, I refer you to Julie's recent blog post:
Left by Chris Falter on May 29, 2008 9:26 AM

Your comment:
 (will show your gravatar)

Copyright © Chris Falter | Powered by: