Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Entity vs. Business Object

time to read 3 min | 444 words

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.



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

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".


Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats