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: 5,968 | Comments: 44,484

filter by tags archive

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.



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. Pointer arithmetic and dynamic HTML generation FTW–at 2 AM - 38 minutes from now

There are posts all the way to Jul 28, 2015


  1. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  2. Production postmortem (4):
    23 Jul 2015 - The case of the native memory leak
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats