**1. Service usage: when you see a hibernate spring tutorial, they all say that for an entity (e.g. User in my case ) you must have a repository called UserRepository with methods like find, findAll, delete, etc. Normally the UserRepository extends some base Repository interface.
Then you have to add the UserService, which injects a UserRepository.
a. Must I have a UserService interface that is implemented by a UserServiceImpl?From my point of view it adds no value to have this. I can have UserService be a class and use Spring's ability to create proxy using GCLIB instead of JDKInterfaces.
b. Is it correct to write the UserService by copying every method from UserRepository and delegating to the @Autowired repository, and then add any other bussiness method?
c. If my UserService doesn't have any bussiness methods, it just delegates everything to the UserRepository, can I just skip the UserService and access directly the UserRepoisitory from my REST layer?
d. Let's say that I also have an Address entity. The user needs an Address when saving ( it is a one2one mandatory ). Is it ok from UserService to inject both UserRepository and AddressRepository inside of it, set up relations there and then call save on each repository? ( don't want to use cascading persist, I want to know how would I do without it since in some situation you cannot use cascading )
2. DTO usage: When you want to read data, you can fetch entities or fetch DTOs directly through JPQL ( or Criteria, I prefer JPQL ).
a. From my point of view, I would always use DTOs instead of entity fetching. It's because, I think SQL is simple, and if i have to think about entities merging, detach, attach , etc, I miss out the entire simplicity of SQL, and ORM becomes an enemy in terms of performance and complexity. So I would use DTO always when I read data and entities when I modify data. What do you think?
b . I want to return all the columns from the User entity. Is it ok to have a UserDTo or I am exaggerating and should just return a User entity? I am 50% - 50% on this.
c. I want to return partially some columns from User. Here I am for 75% DTO and 25% entity. What do you think?
d. I want to return some columns of User and some columns of Address. Here I am 100% for DTO ( although I could just join fetch Address ). What do you think?
Kind regards,
I'll answer them one by one:
1.a) Yes, it does make sense. The Service layer is the transactional boundary and it's where you expose the business logic to the external world through a course-grained interface.
1.b) No, it's not. The UserService define business methods, not data access methods.
1.c) I'd still keep the Service.
1.d) Of course it is. You don't need to call the Services by the entity name. Name it by the business logic concern that they are expressing.
2.a) My rule is simple: entities when you plan on modifying and DTOs for read-only projections.
2.b) Same as 2.a.
2.c) Same as 2.a. If you need to modify the fetched data later, then use subentities.
2.d) Same as 2.a. If you need to modify the data, use entities or subentities. Otherwise, DTOs for read-only projections.