Ayende @ Rahien

It's a girl

Entity vs. Business Object

Rocky Lhotka has posted about ADO.NET Entity Framework, LINQ and CSLA .NET, he included this statement:

Both ADO.NET EF and LINQ work with entity objects - objects designed primarily as data containers. These technologies are all about making it an easy and intuitive process to get data into and out of databases (or other data stores) into entity objects, and then to reshape those entity objects in memory.

CSLA .NET is all about creating business objects - objects designed primarily around the responsibilities and behaviors defined by a business use case. It is all about making it easy to build use case-derived objects that have business logic, validaiton rules and authorization rules. Additionally, CSLA .NET helps create objects that support a rich range of UI supporting behaviors, such as data binding and n-level undo.

It looks like Rocky is talking about entities that mostly server as Data Transfer Objects, with business objects to manage them. This is certainly not the way I view the term Entity.

Using Entities as DTOs is not a good solution in most cases. My entities contains both data and behaviors, and I make full use of the OOP nature of the CLR to make them work very hard for me. From simple things like IsValidForAssignment(Assignment assignment) to complex stuff like business rules that are themselves entities (don't ask, I get head spinnage from thinking about it). What Rocky calls Business Objects I would generally call Controllers, business case driven, using entities (and their logic), etc.

Validation/Authorization I generally kick into their own layers, and I don't worry about the UI so much, if you beat it long enough it will end up looking the way you want it. (Spoken by a person that spend the day making sure that his grids and caledars are printed correctly on multiply pages. There is a reason why I know that the Cyclomatic Complexity of System.Web.UI.Calendar.RenderDays() is 46(!), and it is not a good one).

I am not interested in a flat view of the database, I am much more interested in the behavioral patterns of cooperating entities. The data does come from a database, but that is secondary to the purpose of the entity.

Comments

Jop
02/08/2007 11:56 AM by
Jop

Your link to Lhotka's article does not seem to work.

Jordan Terrell
02/08/2007 05:56 PM by
Jordan Terrell

I agree - Eric Evans (http://www.domaindrivendesign.org/) refers to these as Entities, and they are very much about data AND behavior. I strongly recommed his book "Domain Driven Design".

JT

Comments have been closed on this topic.