Home what is the correct/prefer way of operating repo/service/controller in spring?
Reply: 2

what is the correct/prefer way of operating repo/service/controller in spring?

user1865027
1#
user1865027 Published in 2018-01-11 22:20:06Z

From what I understand, repository does crud, service does all the business logic, and controller receives request. So when a request comes in, the order is usually controller -> service -> repository then pass the data back to client.

The problem I'm facing now is most of my apis would involve in multiple repositories. For example, a request of getting list of email for the user. I would need to decode an encrypted string first (done in UserService). If success, use the id decrypted from string to search for emails (done in EmailService). In this case, the request is first routed to EmailController then calls EmailService. Should I do all the decryption and call UserRepository here in EmailService or have UserService to handle all that? Also, if I wish to return ResponseEntity, should EmailService return a list of emails or ResponseEntity, or have EmailController to construct ResponseEntity?

davidxxx
2#
davidxxx Reply to 2018-01-12 08:50:07Z

There is really distinct approaches but in any case I think that two rules have really to be followed.

First rule : Consistency in the way of proceeding.
If you decide one or two ways according to some conditions, the most important thing is applying it consistently for any application use cases.

If you create unwanted variations the code reading and maintainability will become a nightmare.

Second rule : Make reusable which is designed to be reusable and design a functional design and not a "donkey" one-to-one layers design for each entity/resource because each kind of entity/resource doesn't live alone.


Here you refer to this use case :

a request of getting list of email for the user

Here is a way to process.
I don't tell that it is "the way". It's just my way.

1) Having a one-to-one mapping between the rest controller and the service layer may simplify really your design :

  • EmailController-> EmailService
  • UserController-> UserService

But note that it has a caveat.
If you repeat a similar logic in distinct services classes, it will probably mean that a reusable service used by multiple rest controllers should be introduced.
In this case, you could have for the controllers, a one-to-one mapping between the Controller and the Service layer, that is : EmailController that communicates with an EmailService plus potentially multiple other common services used by EmailController.

From your context, here is a concrete example where a common service should be introduced.
Suppose this task :

"I would need to decode an encrypted string first"

is performed in multiple use cases processed by different controllers, for example EmailController and UserController, it is much better to extract the processing in a dedicated service rather than duplicate it both in EmailService and UserService.

So EmailController would have these dependencies :

- EmailController  -> EmailService
                   -> EncryptingService 

And the same goes for UserController :

- UserController   ->  UserService
                   ->  EncryptingService

2) Services are not designed to have always a one-to-one mapping with the repository layer.
Repositories are indeed designed to be reusable by any services that need them to accomplish their tasks.
So of course UserService is bound to communicate with UserRepository.
But if UserService also needs to retrieve some email entities that are not directly associated to a User entity as an entity relationship, UserService has to interact with EmailRepository to accomplish this task.

So according to your needs, you could have a one-to-one mapping as dependency in UserService :

- UserService  ->  UserRepository                  

or more dependencies :

- UserService  ->  UserRepository
               ->  EmailRepository

3) About this last question

Also, if I wish to return ResponseEntity, should EmailService return a list of emails or ResponseEntity, or have EmailController to construct ResponseEntity?

Don't mix responsibilities otherwise layers loose their values.
Services perform/return functional things and have to be designed to work in this way.
The ResponseEntity wrapping has to be performed in the layer handling HTTP Response, so in the Rest controllers only.

Snickers3192
3#
Snickers3192 Reply to 2018-01-11 23:32:38Z

As you've stated correctly Services contain business logic so they shouldn't be concerned about decryption, IMO this should be hidden within the Repository implementation that is what's causing your design issues with both business logic being mixed with CRUD logic.

Repositories can return paginated results, which is an interface which can be both in the Service and Repository layer. Then in the Controller turn the paginated result into a ResponseEntity, for responding to the request. Don't let the ResponseEntity venture outside of the Controller.

You need to login account before you can post.

About| Privacy statement| Terms of Service| Advertising| Contact us| Help| Sitemap|
Processed in 0.321147 second(s) , Gzip On .

© 2016 Powered by mzan.com design MATCHINFO