[Updated Feb. 13, 2008: A couple of commenters noted that since the generated model is made up of partial classes, then additional partial classes could be developed to encapsulate domain-specific extensions to the model. I hadn't noticed this originally and appreciate it being pointed out to me. With that said, though, this leads me to my next question (since I usually eschew partial-classes): is this a good design practice? My gut tells me that it should be avoided, but perhaps I'm being too closed minded after working with NHibernate since version 0.84.]
For the past year or so, there seems to have been an overwhelming community outcry for getting back to a simpler separation of presentation and logic within ASP.NET applications. The success of Castle MonoRail and the introduction of Microsoft's MVC.NET reflect such direction. So while I applaud Microsoft's bold move towards simpler ASP.NET development, I'm left wanting after taking a closer look at the upcoming ADO.NET Entity Framework.
After spending a few hours playing with ADO.NET Entity Framework Beta 3, using a tutorial for porting ScottGu's MVC.NET code as a starting point, I was left with the feeling that Microsoft has enabled us with terrific ORM generation capabilities; but with the caveat that it can only be used on the most simplistic of CRUD applications. It's quick to setup, it's great with legacy databases, and it makes data communications all but invisible. So what's the rub? The problem, and this is the kicker for me, is that it greatly impairs one's ability to take a domain-driven design approach to product delivery.
In DDD, the business logic lives with the domain objects themselves. As infoq.com eloquently states, DDD "is based on making the domain itself the main focus of the project, and maintaining a software model that reflects a deep understanding of the domain." This idea, that the model reflects the domain itself, is a pivotal one in taking a DDD approach to development. With the ADO.NET Entity Framework, the model is nothing more than a DTO layer with ActiveRecord capabilities; it generates a model layer with get/put statements and persistence methods but without providing the ability to augment the model with domain-specific logic within the model itself.
For example, suppose you have an Employee object generated by the ADO.NET Entity Framework. In less than two seconds, you have a nice Employee object with built-in database communication capabilities. Now suppose you want to add a GiveRaiseOf(Money amount) method to the Employee object which executes a bit of business logic to calculate new estimated taxes or whatever. You cannot add this method directly to the model within an ADO.NET Entity Framework generated model object; alternatively, you could inherit from the generated Employee object and augment it accordingly (ack!) or you create a logic layer which essentially provides a decorated layer of functionality on top of the auto-generated model. (There are other options such as extension methods, AOP, but nothing IMO that provides clean and simple DDD.) Essentially, when using objects generated by the ADO.NET Entity Framework, you're forced to separate domain logic from the model itself; thus, impairing the ability to take a clear DDD path towards development.
I am writing this post for two reasons: 1) to possibly be told that I'm dead wrong and to be explained what the simple way is for augmenting ADO.NET Entity Framework generated model objects with domain-specific logic within the model itself, and 2) to save you some research time if you prefer a DDD approach and it turns out I'm right. ;)
In short, and at the risk of being laconic, I feel that the ADO.NET Entity Framework does for data communications what the ASP.NET page life cycle did for the presentation layer. In trying to introduce simplification and increased productivity, it's actually going to result in higher complexity and decreased maintainability in the long run. I appreciate what Microsoft is trying to do, and absolutely love some of their other ideas, but, for now, I'm going to pass on the ADO.NET Entity Framework.
Billy McCafferty