Home/ Questions/Q 8031149
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T00:59:51+00:00

I have the following doubt. When you have to query a DB from a

  • 0

I have the following doubt. When you have to query a DB from a Java application there are several ways to do it. I have came up with some approaches, but each of them have a con.

The first one is, you have a class eg. QueryManager which provides you with querying functionalities, like executeUpdate(...) and executeQuery(...) while hiding details of the management of connections etc. (Kind of a Facade Pattern). When you need to interact with the DB, you will pass the query as a String and manage the ResultSet.

The problem that I see is that if the DB changes, whether the DBMS or the DB itself, you will end up going file by file modifying the SQL. I see this as a huge dependency. Also, you are exposing to everyone the stucture of your DB and you are making each class to handle the ResultSet. On the other hand, you could achive higher modularity by using this method, since the models (I am a fan of MVC Pattern) of your classes could have package visibility.

The second idea that came to my mind was creating a QueryManager class that instead of providing you with the methods for querying, it will provide you with the methods you need. In other words, each time you need to use the DB, you will create a method in this class, with the SQL inside, that will return the information you need. But, the problem we are facing here is, you have to choose between returning a ResultSet or a model of the data you need.
The former, will make your classes dependant on the DB, less than in the previous example, since now there is no widely spread dependency with the DBMS, because all the SQL is contained in one class/file. However it still exists a dependency with the DB structure and you are exposing, as well, your DB structure to everyone.
The later implies that theese models no longer could be package visibility, they must be public, allowing any class to modify them, and breaking encapsulation.

Is there any other approach that solves all the previous problems? If not, which do you think is a better approach?

I do not think there is an absolute answear (maybe there is), but I must say that we are expecting changes in both the structure of the DB and in the DBMS. This might help in your answear. But try to make it as general as possible, since I could be in other project with the same doubt, but no with the same restrictions.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The second one is the good one: you should extract your data access methods in Data Access Objects (DAOs), which isolate the rest of the application from persistence-related problems. And DAOs should definitely return objects, and not result sets.

    This provides the following advantages:

    • decoupling of concerns and responsibilities
    • easier evolution of the rest of the application when the schema changes
    • easier evolution of the rest of the application when you choose to use an ORM instead of JDBC to access the database
    • easier unit-testing of the queries (and of the persistence layer in general), since the persistence code is not mixed with functional code
    • easier unit-testing of the business (service) layer, because it allows injecting mock DAOs to provide the data, rather than needing real data in the database to test it.
    • 0