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: 18 | Comments: 78

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.


  1. Production postmortem: The industry at large - one day from now
  2. The insidious cost of allocations - about one day from now
  3. Buffer allocation strategies: A possible solution - 5 days from now
  4. Buffer allocation strategies: Explaining the solution - 6 days from now
  5. Buffer allocation strategies: Bad usage patterns - 7 days from now

And 2 more posts are pending...

There are posts all the way to Sep 11, 2015


  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    01 Sep 2015 - The case of the lying configuration file
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats