Design Pattern using Spring Boot instead of DTO, Dao, Service?

user_14515935 0
Viewed 855

I recently started reading a book that explains in more detail the manipulation of databases, in terms of the relationships between them, especially. The problem is that this book is a bit old, from 2014. So I come with the following questions, to which you can clarify, please:

In the book we use Dao, Dto and Service pattern, but we can't use JPA, Spring Boot Repository or other new technologies to "replace" the old implementation that the book presents?

If so, can you give me an alternative to the code below, and how does it work? What could I improve, what could I give up, what should be completed, what should I learn, please!

Book divide the implementations of an Application in 2 teams:

  • UserInterface (Data Transfer Object of the entity, singleton in Memory DB and Controller as Mock Service and view)

  • Development Team (with creating the Entity and testing using TDD, creating DAO for that Entity, Business Service Tier and Presentation Tier

So, I can change this way of creating and manipulating the applications and Databases, if yes, how, and why? What should I use, how should I do it?

This is the git of the book I'm currently reading: https://github.com/Spring-Hibernate-Book/spring-hibernate-datamodeling-tdd-rest/tree/master/Spring-OODD/src

spring-boot hibernate design-patterns database java
1 Answers

As far as division of labor, the concept of having a separate team work on the controller layer seems antiquated. It could be that the single-page-UI has its own team, but many places prefer that the same people work on everything for a feature front to back, in order to reduce opportunities for communication problems between teams.

The extent to which you need DTOs should be up to the developer's discretion. It used to be a practice to routinely copy all entities into DTOs to avoid issues like lazy-loading in the UI. If you are building a single-page application where you're passing JSON to the UI that isn't an issue. The single-page application architecture provides better separation between UI concerns, making DTOs less necessary in most cases.

For the rest of this the concepts should map over. A Spring JPA repository has the same function as a data access object, it just provides more of the implementation for you. The biggest change associated with the Hibernate mappings is to use JPA annotations instead. Services haven’t changed.

TLDR

things that have changed:

  • single-page applications have replaced serverside approaches like JSPs
  • standardizing on JPA instead of Hibernate
  • configuration classes, no application context XML anymore
  • profiles
  • focus on microservices vs. monoliths
  • more batteries-included (h2 by default, deployable jars, convention over config)

things that haven't changed:

  • general layering scheme of controllers calling services calling data access
  • Hibernate mapping strategies and general ORM issues
  • Spring transaction support
  • general Spring programming model with beans, DI, AOP
user_2173240
Related