Home/ Questions/Q 6131065
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T16:55:51+00:00

With the introduction of Hibernate in my project, my code started getting really coupled,

  • 0

With the introduction of Hibernate in my project, my code started getting really coupled, and boilerplate in many places (and it should be the other way round, right?)

I got pretty confused by a particular example. I’ve always considered DAO objects to be pretty generic in their nature (mostly encapsulating the basic CRUD oeprations as well as the backend storage implementation)

Unfortunately, as my entity classes started to get more complicated, I started offloading more and more logic to the DAO objects. I have a particular example:

my entity class User should have a relation called friends, which is essentially a collection of users. However, I have to map my class to a collection of UserFriendship objects instead, each of which contains a ref to the friend object, but also other specific friendship data (the date when the friendship occurred)

Now, it is easy to introduce a custom getter in the entity class, which will take the collection of UserFriendship objects and turn it into a collection of User objects instead. However, what if I need only a subset of my friends collection, say, like in paging. I cannot really do that in the entity object, because it doesn’t have access to the session, right? This also applies to when I need to make a parametrized query on the relationship. The one that has the access to the session is the UserDAO. So I ended up with this

UserDAO
=> normal CRUD methods
=> getFriends(Integer offset, Integer limit);
=> a bunch of similar getters and setters responsible for managing the relationships within the User instance.

This is insane. But I cannot really do anything else. I am not aware if it is possible to declare computed properties within the entity classes, which could also be parametrized.

I could technically also wrap the DAO within the entity, and put the helper getters and setters back into the entity class, where they should be, but I am not sure whether if that is a good practice as well.

I know that the DAO should only be accessed by the controller object, and it should provide a more or less complete entity object or a set of entity objects.

I am deeply confused. More or less all of my DAO objects now couple logic that should be either in the Entity objects or in the controllers.

I am sorry if my question is a bit confusing. It is a bit hard to formulate it.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    My general rules are:

    • in the entity classes, respect the law of Demeter: don’t talk to strangers
    • the entity classes must not use the session
    • the controller/service classes must not use the session. They may navigate in the graph of entities and call DAO methods
    • DAO methods should be the ones using the session. Their work consists in getting, saving, merging entities and executing queries. If several queries or persistence-related actions should be executed for a single use-case, the controller/service should coordinate them, not the DAO.

    This way, I can test the business logic relatively easily by mocking the DAOs, and I can test the DAOs relatively easily because they don’t contain much logic. Most of the tests verify that the queries find what they’re supposed to find, return them in the appropriate order, and initialize the associations that must be initialized (to avoid lazy loading exceptions in the presentation layer, where I’m using detached objects)

    • 0