This scenario refers to systems where the inputs retrieved are simple to manage and persist in the database. However, before delivering information to users, many transformations are needed to make the data useful and comprehensive for the business.

Imagine a system where the code is comprised of a large set of entity objects mapping database tables to persist information using an ORM framework. This kind of system involves many writes and read operations that are executed using the ORM and some operations that run as part of the system to transform the retrieved data—in the form of entity objects—into data transfer objects (DTOs) to provide information in a meaningful way for the business.

The following diagram shows the dataflow from the database to the business services that is designed to follow this approach:

Transforming data is not a big deal. In systems using an ORM, the biggest problem arises when entity objects bring columns containing useless information that is ignored during the transformation process, introducing an unnecessary overhead on the database and the network. On the other hand, in the preceding diagram, we can see that a big process is needed to map the database tables as objects before actually getting the requested data. A good approach to getting rid of this problem is to replace the read operations executed by the ORM frameworks with stored procedures or plain query statements to retrieve only the required data from the database.

The following diagram shows how entity objects can be replaced with DOTs:

It's evident that this approach is much more simple and easy to accomplish. Even the amount of code required is drastically reduced. I'm not concluding that ORM frameworks are bad—actually, many of them are awesome, and projects such as Spring Data provide tons of built-in features. However, depending on the business requirements, plain JDBC operations are sometimes much more beneficial for the system.