Take the 2-minute tour ×

In our legacy Java EE application, there are loads of value object (VO) classes which typically contain only getters and setters, maybe equals() and hashCode(). These are (typically) the entities to be saved in persistence storage. (For the record, our app has no EJBs - although that might change in the future -, and we use Hibernate for persisting our entities.) All the business logic to manipulate the data in VOs is in separate classes (not EJBs, just POJOs). My OO mindset hates this, as I do believe that the operations on a given class should reside in that same class. So I have an urge to refactor to move logic into the related VOs.

I just had a discussion with a co-worker who is much more experienced in Java EE than me, and he confirmed that dumb entities at least used to be the recommended way to go. However, he has also read opinions recently which question the validity of this stance.

I understand that there are issues which at least limit what can be put inside an entity class:

  • it should not have direct dependency to the data layer (e.g. query code should rather go into separate DAOs)
  • if it is directly exposed to higher layers or to the client (e.g. via SOAP), its interface may need to be limited

Are there any more valid reasons not to move logic into my entities? Or any other concerns to take into account?

share|improve this question
Are the Entities the VO? –  Pascal Thivent Feb 25 '10 at 11:06
@Pascal Yes - see my update. –  Péter Török Feb 25 '10 at 11:18

7 Answers 7

up vote 12 down vote accepted

The DTO and VO are supposed to be used to transfer data and don't embed logic. The business objects on the other hand are supposed to embed some logic. I say some, because there is always a balance to find between what you put in services which coordinate logic involving several business objects and what you put in the business objects themselves. Typical logic in the business objects can be validation, field computation, or other operation that impact only one business object at a time.

Note that I haven't mentioned the term entity so far. Persistent entities were popularized with ORM and we nowadays try to use persistent entities both as DTO and business object at the same time. That is, the entity themselves flow between layers and tiers, and contain some logic.


As you pointed out, it's all a matter of dependencies and what you expose. As long as the entities are dumb (close to DTO) they can be isolated in a dedicated jar easily that serves as API of the layer. The more logic you put in the entities, the harder it becomes to do that. Pay attention to what you expose and what you depend on (the load the class, the client will need to have the depend class as well). This applies to exceptions, inheritance hierarchy, etc.

Just to give an example, I had a project where the entities had a method toXml(...) used in the business layer. As a consequence, client of the entities depended on XML.

But if you don't care too much about layers, and strict separation between API and implementation, I think it's good to move some logic in the entities.


This question has been discussed many time and will probably continue to be discussed as there is no definitive answer. A few interesting links:

share|improve this answer
I found most answers useful and it was difficult to pick one as "the best". However, I found yours the most balanced and insightful, so you get the check mark :-) Thanks. –  Péter Török Mar 1 '10 at 21:37
Yes, having re-read this more than a year afterwards I have to agree that ewernli definitely knows his way around on this topic. –  James Poulson Aug 9 '11 at 21:18

I think your point is valid.
See this for more - http://martinfowler.com/bliki/AnemicDomainModel.html
With JPA, the Entities are light-weight objects. So I don't think its any problem having logic in them.

In case of use with SOAP/Web Services, I'd add a separate Facade Layer.

share|improve this answer
Agreed. Using objects with only getters and setters goes completely against OO and is more like using structs in C. I like C, but this is Java and I cringe everytime I have to wade trhough a class containing nothing else but boiler-plate code in the form of getX() and setX() –  Martin Wickman Feb 25 '10 at 11:43
@Padmarag Excellent article, thanks :-) –  Péter Török Feb 25 '10 at 12:28
I wish it was that simple :) –  ewernli Feb 25 '10 at 12:32
@James P. Why couldn't it? I don't see your point. –  Péter Török Feb 25 '10 at 13:58
I think the issue with calling MVC a pattern is that it is really a combination of 3 GoF design patterns: Observer, Composite, and Strategy. The conjunction of these three patterns forms an "architectual" design pattern. –  Matthew Flynn Feb 26 '10 at 1:25

Beyond the Fowler article mentioned earlier, there is a full treatise on rich vs. anemic domain models in Eric Evans's book Domain Driven Design(2004).

Also, check out http://dddcommunity.org/

share|improve this answer
You really need to read this book. It's one of those rare cases where a work is both seminal and useful. –  HDave Oct 31 '13 at 12:45

Right, here's a summary of the feedback I got from my Java EE trainer.

From a pratical point of view, striking a compromise between anemic and rich domain by moving logic shouldn't a problem as long as the methods work with the attributes of the Entity. When it comes to a rich domain, the line has to be drawn somewhere and apparently both Fowler and King have emitted comments in that direction.

For example, consider a calculateInterestRate() method inside a BankAccount that fetches information from other domain objects like verifying how long someone has been a client. To avoid dependency, one could split the method accross objects but this approach means that code can end being strewn accross several classes. At this point, one might as well make a InterestCalculator class.

Another thing to take into account is thread safety. Singleton DAOs and Services handled by Spring should be thread safe whereas anything in the domain model will be exposed to concurrency issues.

Lastly, there's the problem of maintenance. Are you sure you will be around to maintain the application in a couple of year's time? The choices you make may appear to be justified but are you certain that the next developper will have the expertise necessary to easily understand your code?

share|improve this answer

The convention you are referring to is to adopt an anemic domain model, as opposed to rich domain model, where Entities are simple POJOs annotated as beans (@Entity) with just the bare minimum in terms of getters and setters. So a class with a toXML() method would be considered as rich domain. I guess it helps to keep a clear view of what is being mapped to a relational database even if granularity differs.

The advantage is that there is a clear separation between logic and data (this is where the OO philosophy is broken). The approach is to group these into business logic classes or Services. This is according to a layered architecture with respective layers being Domain, Services, DAO and UI.

That's the theory.

Edit: Just to clarify, when I say there's a clear separation between logic and data, I mean that one object is data orientated and another is method orientated in a way that could be considered as a lapse back to procedural.

share|improve this answer
@James P. I am afraid you don't quite understand the point of OO if you consider it "broken" because of this :-( –  Péter Török Feb 25 '10 at 14:06
It's possible and I'm always open to enlightenment ;) . Correct me if I'm wrong but it sounds like the encapsulation principle is at the center of the debate here. –  James Poulson Feb 25 '10 at 15:19
P. I am not sure I understand where you are aiming to. Anyway, I would not like to "debate" about OO because a) I would prefer to keep this topic on focus, b) opinions about OO are (rightly) subjective and context-dependant, c) 600 chars would not be enough for this anyway. –  Péter Török Feb 25 '10 at 21:58
I've posted a second answer with a summary of some feedback that a contact has given me on the question. –  James Poulson Feb 26 '10 at 12:29

The main problem with adding logic to those classes is, they would need more attributes to keep track the object state, and these extra attributes generally do not need to be serialized. This means extra work is needed in the serialization mechanism of those classes.

Considering that many projects have a mixture of jr. programmers and sr. programmers and most of the work is performed by the jr's who don't understand ( or care ) about optimal serialization, it is much more easy to have this plain old java objects as "value objects" which pretty much just pass and receive data and put the logic in other place.

If you manage to have an architecture where the logic is placed in a business object ( that is VO + Logic ) I think that would be better also. Just bear in mind the whole team is in the same page and they don't duplicate code and logic ( which never happens right? )

Short answer: No, they should not be dumb always, but is a much easier to have them that way.

share|improve this answer
If serialization is an issue, you can make the additional attributes transient. Not a big deal. –  Matthew Flynn Feb 25 '10 at 17:32
@Matthew of course, as long as newbies understand what are you talking about. –  OscarRyz Feb 26 '10 at 14:32

I have done some C programming and while OOP is nice for simplifying problems by building class hierarchies, I still find the simple C approach the simplest and greatest in many cases. In C we have structs with only public members, and the programmer passes in such structs to functions (in Java such functions would be e.g. static functions in some utility class) which functions manipulate the members. The data and the algorithm is separated as the functions are not members of the structs. I always had the feeling that VO objects are like structs in C.

There are lots of cases when the C language is not the greatest, because e.g. there is no hierarchy, there is no polymorphism, things that decent OOP programmers find useful. However in general I like this simple C approach and prefer to use it unless I know that an OOP technique would be really beneficial. E.g. when I need to use a hierarchy of classes to model something or I need to make sure that members of one or more classes (in a hierarchy) are always consistent with each other then I cannot use the C struct approach. But in these cases I would not only have setters and getters anyway.

I'd also refer this article which is about C++ but I love how this guy explains such things: http://www.gotw.ca/gotw/084.htm This article has 2 rules about when to make a function the member of a class:

(from the quote below I am leaving out some things, read the original if you want to see all)

  1. Always make it a member if it has to be one: Which operations must be members, because the C++ language just says so (e.g., constructors) or because of functional reasons (e.g., they must be virtual)? If they have to be, then oh well, they just have to be; case closed.

  2. Prefer to make it a member if it needs access to internals: Which operations need access to internal data we would otherwise have to grant via friendship? These should normally be members.

In all other cases, prefer to make it a nonmember nonfriend: Which operations can work equally well as nonmember nonfriends? These can, and therefore normally should, be nonmembers. This should be the default case to strive for.

I have the feeling that if you are in doubt whether to add functions to these classes you do not have the real need to do so. What I wrote here is only a part of all the reasons why I would not add methods to such classes however maybe this is the father of all my other reasons. But this is all subjective so YMMV. BTW the static utility functions approach makes unit testing simple in most cases.

share|improve this answer

Your Answer


