Not long ago, an article on the Internet caught my attention. It described an intriguing approach to combining Generics and Spring capabilities. It reminded me of the method that I tested in my private programming experience. I want to present it here and show how we can use the Java Generics mechanism for building an abstract architecture.<\/p>\n\n\n\n
As a result, we can obtain a system where adding a new entity requires just initializing one bean in each part of the repository-service-controller trio. I assembled the project using Spring Initializr, adding JPA, Web, and H2 frameworks with Gradle and Spring Boot 3.1.3.<\/p>\n\n\n\n
To begin with, let’s examine the classic scenario of transferring data between the controller and the repository without any additional logic.<\/strong> If you are eager to dive into the core of this approach, feel free to scroll down to the abstract version. However, I still recommend reading the entire article.<\/p>\n\n\n\n We will not be distracted by essential matters like validation, DTO mapping, and other details. Let\u2019s concentrate solely on the differences between classic and abstract approaches to constructing all layers of the application.<\/p>\n\n\n\n This section defines the User class, which represents a domain entity. It is annotated with @Entity, indicating that it is a JPA entity.<\/p>\n\n\n Here, the UserRepository interface is defined, extending the CrudRepository interface for the User entity.<\/p>\n\n\n The UserService interface is introduced, defining a contract for working with user-related operations.<\/p>\n\n\n The UserServiceImpl class implements the UserService interface. It is annotated with @Service, indicating that it is a Spring service component.<\/p>\n\n\n In this section, the UserController class is defined as a Spring REST controller. It is responsible for handling HTTP requests related to users. The class has a constructor that takes a UserService as a parameter, and it uses dependency injection to initialize it.<\/p>\n\n\n At the end, we have a set of dependent classes that will assist us in operating the User entity at the CRUD level. Let’s say we need to add another entity, for example, Car. We will not map them to each other at the entity level (if you wish, you can create mappings). To begin, let’s create the entity.<\/p>\n\n\n Then, we need to create the repository.<\/p>\n\n\n Next, the service.<\/p>\n\n\n Then, the service implementation, Controller, etc.Yes, you can simply copy and paste the same methods (since they are universal) from the User class, then replace “User” with “Car”, and repeat the same process for the implementation and the controller. Then, another entity is in the queue, and more and more keep appearing.<\/p>\n\n\n\n Usually, one can become exhausted even after the second entity. Creating a utility architecture for a couple dozen entities (copy-pasting, replacing entity names, making mistakes here and there) leads to struggles caused by any monotonous work. Try to write twenty entities on your free time, and you’ll understand what I mean.<\/p>\n\n\n\n At one point, while delving into generics and type parameters, it dawned on me that this process could be approached differently, providing us with the opportunity to write a smaller amount of code.<\/p>\n\n\n\n Abstractions based on type parameters \u2014 the essence of this strategy is to extract all the logic into an abstraction, bind that abstraction to type parameters of an interface, and inject other beans into it. That\u2019s it. No logic in the beans themselves \u2014 only the injection of other beans. This approach involves writing the architecture and logic once, eliminating duplication when adding new entities. <\/p>\n\n\n\n Let’s begin with the cornerstone of our abstraction: the abstract entity. From this entity, the chain of abstract dependencies will commence. All entities share at least one common field, usually more: the ID. We will extract this field into a separate abstract entity and inherit it for both User and Car.<\/p>\n\n\n\n Do not forget to annotate the abstraction with @MappedSuperclass. Hibernate should also recognize it as an abstraction.<\/p>\n\n\n\n With Car, the same approach applies accordingly.<\/p>\n\n\n\n In each layer, apart from the beans, we will have one interface with type parameters and one abstract class with logic, except for the repository – thanks to the specificity of Spring Data JPA, things will be much simpler here.The first thing we will need in the repository is a common repository.<\/p>\n\n\n\n In this repository, we establish common rules for the entire chain: all entities participating in it will inherit from the abstract one. We use the @NoRepositoryBean annotation here to indicate that we do not want Spring to create an instance of this repository. Therefore, a Bean of this repo will not be created during the context creation.<\/p>\n\n\n\n Next, for each entity, we need to write its own repository interface where we specify the exact entity with which this repository-service-controller chain will work.<\/p>\n\n\n\n With this, thanks to the features of Spring Data JPA, the repository configuration is now complete, and everything will work as expected. Next comes the service. We need to create a common interface, abstraction, and bean.<\/p>\n\n\n\n In this step, we override all methods and also create a parameterized constructor for the future repository, which we will override in the bean. In this way, we are already using a repository that we have not defined yet. We do not know which entity will be processed in this abstraction and which repository we will need.<\/p>\n\n\n\n In the bean, we perform the final step \u2014 explicitly defining the necessary repository that will be called in the constructor of the abstraction. And that’s it. <\/p>\n\n\n\n Using the interface and abstraction, we have created a mainline through which all entities will pass. In the bean, we create the branching point from which we will connect the desired entity to the mainline.The controller follows a similar principle: we create an interface, abstraction, and bean for it.<\/p>\n\n\n\n And that\u2019s it: this is the entire structure. What’s next?<\/p>\n\n\n\n Now, let’s imagine that we have a new entity. We have already inherited it from AbstractEntity, and we need to establish the same chain for it. This will take us a minute. No copy-pasting or corrections required. Let’s consider the Car entity, which is already inherited from AbstractEntity.<\/p>\n\n\n\n As we can see, duplicating the same logic involves simply adding a bean. There’s no need to rewrite the logic for each bean with parameter changes and signatures. These aspects are written once and work in every subsequent case.<\/p>\n\n\n\n Of course, the example described is a kind of situation in vacuum where CRUD for each entity share the same logic. Such situations rarely occur \u2014 there will still be a need to override some methods in the bean or add new ones based on specific entity processing requirements. It’s good if around 50% of the total CRUD methods remain in the abstraction. This would be beneficial because the more unnecessary code we manually generate, the more time we spend on monotonous work, and the higher the risk of errors or typos.<\/p>\n\n\n\n However, it’s important to acknowledge that this strategy can lead to code that may appear cumbersome and unreadable in enterprise-level projects. Therefore, I can recommend this strategy only for developing some smaller projects. It allows you to experience its pros and cons of this strategy and consider how it might be enhanced and made more suitable for larger, more complex projects.<\/p>\n\n\n\n I hope you found this article helpful and interesting. Thank you for your attention. You can find the examples from this article on the public repository on GitHub<\/a>.<\/p>\n\n\n\n ***<\/p>\n\n\n\n If you’re curious about spring, also take a peek at other articles by our experts<\/a>.<\/p>\n\n\nClassic Version<\/strong><\/h2>\n\n\n\n
Domain<\/strong><\/h3>\n\n\n\n
\n@Entity\npublic class User implements Serializable {\n\n private Long id;\n private String name;\n private String phone;\n\n \/\/getters, setters, equals, hashcode, toString\n}\n<\/pre><\/div>\n\n\nRepository<\/strong><\/h3>\n\n\n\n
\n@Repository\npublic interface UserRepository extends CrudRepository<User, Long> {\n}\n<\/pre><\/div>\n\n\nService Interface<\/strong><\/h3>\n\n\n\n
\npublic interface UserService {\n\n Optional<User> save(User user);\n}\n<\/pre><\/div>\n\n\nService<\/strong><\/h3>\n\n\n\n
\n@Service\npublic class UserServiceImpl implements UserService {\n\n private final UserRepository userRepository;\n\n @Autowired\n public UserServiceImpl(UserRepository userRepository) {\n this.userRepository = userRepository;\n }\n\n @Override\n public Optional<User> save(User user) {\n return Optional.of(userRepository.save(user));\n }\n}\n<\/pre><\/div>\n\n\nController<\/strong><\/h3>\n\n\n\n
\n@RestController\n@RequestMapping("\/user")\npublic class UserController {\n\n private final UserService service;\n\n @Autowired\n public UserController(UserService service) {\n this.service = service;\n }\n\n @PostMapping\n public ResponseEntity<User> save(@RequestBody User user) {\n return service.save(user).map(u -> new ResponseEntity<>(u, HttpStatus.OK)).orElseThrow(() -> new UserException(\nString.format(ErrorType.USER_NOT_SAVED.getDescription(), user.toString())));\n }\n}\n<\/pre><\/div>\n\n\nAdding another entity<\/strong><\/h2>\n\n\n\n
\n@Entity\npublic class Car implements Serializable {\n\n private Long id;\n private String brand;\n private String model;\n\n @Id\n @GeneratedValue\n public Long getId() {\n return id;\n }\n\n public void setId(Long id) {\n this.id = id;\n }\n\/\/getters, setters, equals, hashcode, toString\n}\n<\/pre><\/div>\n\n\n\npublic interface CarRepository extends CrudRepository<Car, Long> {}\n<\/pre><\/div>\n\n\n\npublic interface CarService {\n\n Optional<Car> save(Car car);\n\n List<Car> saveAll(List<Car> cars);\n\n Optional<Car> update(Car car);\n\n Optional<Car> get(Long id);\n\n List<Car> getAll();\n\n Boolean deleteById(Long id);\n\n Boolean deleteAll();\n}\n<\/pre><\/div>\n\n\nAbstractions based on type parameters<\/strong><\/h2>\n\n\n\n
AbstractEntity<\/strong><\/h3>\n\n\n
\n@MappedSuperclass\npublic abstract class AbstractEntity implements Serializable {\n\n private Long id;\n\n @Id\n @GeneratedValue\n public Long getId() {\n return id;\n }\n\n public void setId(Long id) {\n this.id = id;\n }\n}\n<\/pre><\/div>\n\n\nUser<\/strong><\/h3>\n\n\n
\n@Entity\npublic class User extends AbstractEntity {\n\n private String name;\n private String phone;\n \n \/\/...\n}\n<\/pre><\/div>\n\n\nCommonRepository<\/strong><\/h2>\n\n\n
\n@NoRepositoryBean\npublic interface CommonRepository<E extends AbstractEntity> extends CrudRepository<E, Long> {}\n<\/pre><\/div>\n\n\nUserRepository<\/strong><\/h3>\n\n\n
\n@Repository\npublic interface UserRepository extends CommonRepository<User> {}\n<\/pre><\/div>\n\n\nCommonService<\/strong><\/h3>\n\n\n
\npublic interface CommonService<E extends AbstractEntity> {\n Optional<E> save(E entity);\n\/\/... other methods\n}\n<\/pre><\/div>\n\n\nAbstractService<\/strong><\/h3>\n\n\n
\npublic abstract class AbstractService<E extends AbstractEntity, R extends CommonRepository<E>> implements CommonService<E> {\n protected final R repository;\n\n @Autowired\n public AbstractService(R repository) {\n this.repository = repository; }\n\/\/\u2026 other methods overridden from interface }\n<\/pre><\/div>\n\n\nUserService<\/strong><\/h3>\n\n\n
\n@Service\npublic class UserService extends AbstractService<User, UserRepository> {\n\n public UserService(UserRepository repository) {\n super(repository);\n }\n}\n<\/pre><\/div>\n\n\nCommonController<\/strong><\/h3>\n\n\n
\npublic interface CommonController<E extends AbstractEntity> {\n\n @PostMapping\n ResponseEntity<E> save(@RequestBody E entity);\n\n\/\/ other methods }\n<\/pre><\/div>\n\n\nAbstractController<\/strong><\/h3>\n\n\n
\npublic abstract class AbstractController<E extends AbstractEntity, S extends CommonService<E>>\n implements CommonController<E> {\n\n private final S service;\n\n @Autowired\n protected AbstractController(S service) {\n this.service = service;\n }\n\n @Override\n public ResponseEntity<E> save(@RequestBody E entity) {\n return service.save(entity).map(ResponseEntity::ok)\n .orElseThrow(() -> new SampleException(\n String.format(ErrorType.ENTITY_NOT_SAVED.getDescription(), entity.toString())\n ));\n }\n\n\/\/ others methods\n}\n<\/pre><\/div>\n\n\nUserController<\/strong><\/h3>\n\n\n
\n@RestController\n@RequestMapping("\/user")\npublic class UserController extends AbstractController<User, UserService> {\n\n public UserController(UserService service) {\n super(service);\n }\n}\n<\/pre><\/div>\n\n\nCarRepository<\/strong><\/h3>\n\n\n
\n@Repository\npublic interface CarRepository extends CommonRepository<Car> {}\n<\/pre><\/div>\n\n\nCarService<\/strong><\/h3>\n\n\n
\n@Service\npublic class CarService extends AbstractService<Car, CarRepository> {\n public CarService(CarRepository repository) {\n super(repository); }}\n<\/pre><\/div>\n\n\nCarController<\/strong><\/h3>\n\n\n
\n@RestController\n@RequestMapping("\/car")\npublic class CarController extends AbstractController<Car, CarService> {\n\n public CarController(CarService service) {\n super(service);\n }\n}\n<\/pre><\/div>\n\n\nConclusion<\/strong><\/h2>\n\n\n\n