Home/ Questions/Q 640203
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T20:55:39+00:00

In our legacy Java EE application, there are loads of value object (VO) classes

  • 0

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

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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:

    • 0