DTO's, DAO or Service layer?

Question

My application is based on the typical 3-tier layer architecture and the goal is to create a SpringMVC site and a Spring Batch solution which feeds and maintains our database's products and stock, where speed is a very important factor.

I'm using Spring's JdbcTemplate to manage a legacy database. Some of my tables contains lots of columns I don't use, and retrieving the whole rows has shown a negative impact due to the size of some fields (blobs we don't even need to map), so I created some beans matching the columns I want to retrieve, such as:

• Product -- Contains a 1:1 relation with the fields stored in the DB.
• ProductDetailsView -- Contains id, name, price, description, stock.
• ProductListItemView -- Id, Price, name, stock.

The DAO layer returns these beans to the service layer. AFAIK creating a DTO to expose it in my services interface for Product might make sense, but,

1) What about ProductDetailsView and ProductListItemView?

2) Should I do a 1:1 mapping from these 'views' or 'projections' into DTOs with the same attributes? Why?

3) In any case, where would you place JSR-303 annotations to validate the web's input?

Answer 1

Normally the use of DTO is due to decouple the entities from the view, then any internal change in the database won't impact the view or the clients and views does not require to change at all. Unless you require to send more or different information. But you are not using JPA you are using jdbctemplate so your objects could act immediately as a DTO as you are not tied to your database model.

For the Product entity it seems that the creation of a DTO is a good approach as your view object is only a partial representation of the entire object stored in the database.

1. I see that there is a minimum number of columns there in ProductDetailsView and ProductListItemView, (probably you just put a set), if you consider you wont have much changes in the definition of the tables, as they are not so big you could use the entities objects like a rest repository approach.

2. Projections is also a different approach to solve the same requirement avoiding send the information that does not matter to the view, but you will contains jackson annotations and jpa annotation in the same POJO. (This is more when you are using an ORM). People dont like that so much, that is why the approach to create the DTO's

3. Normally JSR303 annotations belongs to the 'input' objects, they are checking as soon as they reach the controller, you could use the @Validated annotations that play very well with springmvc and jsr, this is used in the methods that belong to your endpoints.

I think there is not a golden rule, but I will try to decouple the view of the database layer the much that I can. And as you are using jdbcTemplate you dont need to worry about bring entire representation or have issues with eager/lazy collections of the table, as you can always modify the projection to use get what you will use. Consider bring from the DAO the DTO that you will send to the view and use the same as an input object in your CRUD operations