What is the design pattern to use to save objects that have similar ways to save?

Asked

Viewed 338 times

3

I have this doubt because if I am not mistaken I have read, seen, or even implemented something of this type but I am no longer remembering, it is the following:

I have here an EJB project with several entities, some of them have very similar ways of saving as for example the entity Contract and Financial Assistance, these two (and more) will implement a list of Competencies and save other basic attributes. The point is that so I don’t have to implement several Services and several Daos with the same save methods by changing a little thing here or there I think I could have something like a service or generic dao that picked up the object of any entity and the entity itself if in charge of saving himself.

We try to do with a Factory that creates the dao corresponding to the type of the passed object but I think that is not yet there... I don’t know for sure but maybe even using addiction injection would be a lot more elegant... Someone could give me a light?

  • 1

    You are using JPA? If yes the EntityManager can be used to persist any entity. While for architectural reasons it is interesting to centralize access to bank, Daos are certainly not a requirement. If you want to adopt a standard recommend the Spring Data JPA, with it you will basically only declare extending interfaces CrudRepository in the basic case, it does all the rest for you.

  • Yes @Anthony Accioly, I am using JPA. I know that Entitymanager is capable of saving any entity but I will have to create the DAO of each entity, right? I’ll take a look at the Spring Data JPA to see if it covers the desired...

  • 1

    Vinicius, not by necessity. DAO is a standard like any other; you can get Entity Manager wherever you want (in your - rich - domain layer for example, or directly in the service layer if isolating access to the bank is not a priority). Personally I like to have a layer of Daos or Repositories to centralize access, but this is by no means a requirement.

1 answer

3


I don’t know a design pattern to do this directly. However, there are several techniques to achieve this goal.

Aspect-Oriented Programming (AOP)

The Spring Data JPA project, cited by @Anthonyaccioly, is an example of AOP usage. It allows automatic "generation" of Repositories to interface with the database based on interfaces.

Basically, you declare an interface that extends the interface JPARepository spring. spring does the rest.

For example:

public interface UserRepository extends JpaRepository<User, Long> {

  List<User> findByLastname(String lastname);

  User findByEmailAddress(String emailAddress);
}

Only through the signatures above will Spring be able to provide the implementation of the methods and inject a bean concrete where you need.

In addition, the interface JPARepository already comes with several basic methods for Cruds.

Note that Repository is the name of a project pattern. It is analogous to DAO, the difference is that the DAO interface follows the pattern of a database while Repository follows the pattern of a Collection.

Generic ()

This Java language feature is excellent for this type of task. If there are several classes that are used in virtually equal operations and it is not possible or desirable to use polymorphism for this, simply declare a class that performs these operations with the parameterized type.

I won’t detail the implementation here because it would be an extremely long answer. But just search a little to find some implementations existing.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.