4

A question came to the team and I'm asking you guys. Our application uses MVC with service layer. But sometimes our service layer just call the repository, without doing nothing

Our questions is: in this cases is it ok to call the repository directly from controller? For example: let's say a controller that call service when have business logic and then the service calls the repository. But when there's no logic to use in just a direct select, the controller would call the repository.

5

If your repository layer is properly abstracted (eg, the service layer and controller can only access the repository via interfaces), then:

  1. Having the controller access the repository directly simplifies that part of the code as it removes an unnecessary level of abstraction, but
  2. You are then coupling the controllers to both the service and repository layers, which can increase complexity, and
  3. You may be creating a maintenance problem should you need to add business logic at that point in the future and thus would have to "re-plumb" that part of the code, but
  4. The YAGNI ("You ain't gunna need it") principle comes in to play here, so it's unlikely you should allow such potential future issues to affect the design now.

On balance, I'd stick with feeding everything through the service layer. But that's pure opinion; accessing the repository directly is equally valid.

If your repository layer isn't properly abstracted (ie the service layer deals directly with concrete repository/database classes), then:

  1. Fix it!
  2. Do not have the controllers go anywhere near the repository until you have fixed it, as this path leads to testing hell.
  • 1
    Don't worry, our repository layer is abstracted :) Considering that our code is already using the service layer, we choose to stick with it. But on another projects, I'll think about it first. – Welliton Paiva May 23 '18 at 16:58
3

It's better to be consistent and always call the service layer even as a pass through. Consistency is more important than saving a few lines of uninteresting code. This allows you to add potential business logic to accommodate future changes, and can help act as a signal that you aren't separating your business logic as much as you should if you have a lot of empty methods in your service layer.

A large part of being able to maintain a project is that there are very few/no areas that behave unexpectedly and don't follow the same patterns.

2

The dependencies required for the repository classes shouldn't be needed by the controller classes. If you don't mind having the dependencies there, I suppose you could skip the pass-through call and go straight to the repo.

It boils down to do you care that the controller now has a dependency on the repositories.

I've made the assumption that your repositories are an abstraction above the actual datastore, and you're not calling directly into a database or file system or what have you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.