Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recently I was faced a question about whether a simple calculation should be put in the Entity layer, or should the Entity be pure for just storing the raw data and leave the calculation logics in the business layer.

So my question is whether it is sensible to encapsulate simple calculations in the properties in an entity class?

share|improve this question

migrated from Jan 10 '12 at 5:09

This question came from our site for professional and enthusiast programmers.

It depends on the type of architecture you want.

  • In Domain Driven Design, you would create a Domain Model that would have both data and functionality.

This would mean that an Order has a property (or method) that would return the total price of the order based on the OrderLines. The Order would also have a method AddOrderItem(Product product, int amount) and the Order would check if there is already an OrderLine for that specific product.

In such a model you would also have objects that are not real entities, like a Repository for accessing data or a Factory for creating entities. These are called Domain Services. An Application Layer is responsible for calling the Domain Services (for example to retrieve an entity from the database) and then it will execute functionality on the entity. The Application Layer should be as thin as possible.

This is a nice article about DDD which explains these concepts in more detail.

  • You can also use an Anemic Domain Model. That means that your entities consist of get/set properties and contain no behavior. In such a design, your Business Layer will contain the behavior, such as calculating the Order price and checking for duplicate OrderLines.

There are different opinions whether an Anemic Domain Model is a bad thing. Personally I prefer a real Domain Model.

This article describes the differences between an Anemic and non-Anemic Domain Model.

share|improve this answer
Hi Wouter, thanks for the answer and the links. I seem to face a wrong mind set that when used the Anemic domain model, all the business logics(even the very simple ones) should be put in the business layer. This seems non-sense in some cases where the business logics are really just depending on the model itself. For example, a property is calculated from the existing properties in the model. I couldn't find a sensible reason for putting the business logics that all depends on the model itself into the business layer. – Katat Jan 10 '12 at 3:12

Well, Entity and business Objects are almost same, most of the time. For example if you have a product class and you want to expose a property which takes some existing property in product class and does some calculation and then exposes it. Its fine in the term that, the logic of creating that property remains with the class.

Now, the question may come, where to fit your business layer class. I prefer using business layer class which has some logic to deal with business problem. For example in your Product example, a business problem could be charging money using third party vendor like paypal.

One key thing to remember is an Entity would always have an identity but a business object are entity with out an identification. For example product is an entity but money would not have an identity. 1000 different instances of money would be same.

share|improve this answer
Yes. If the property's business logic all depends on the existing properties on the same model, it would be better to just add the property in the model. This would help loose the unnecessary couple with the business layer for the calculated properties. – Katat Jan 10 '12 at 3:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.