Should Enterprise Java entities be dumb?

Question

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?

Answer 1

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.

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

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.

EDIT

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

• Getter Eradicator
• Anemic domain model
• The importance of being closed
• Domain Modeling
• Where does my business logic go?
• Transfer object vs. business object

Answer 2

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.

Answer 3

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/

Answer 4

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.

Answer 5

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.

Answer 6

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?