Should Enterprise Java entities be dumb?

Question

In our legacy JEE 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 JEE 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

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 2

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.

Answer 3

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 4

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 5

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://domaindrivendesign.org/

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?