Calling service and repository layer from controller

Question

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.

Answer 1

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.

• Welliton Paiva: 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.

Answer 2

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.

Answer 3

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.

Answer 4

• Generally there is no issue with direct controller to reposiroty approach. it will work but it can lead to tightly coupled and harder-to-maintain code as the project grows.

• What is service layer? Microsoft says "A service layer is an additional layer in an ASP.NET MVC application that mediates communication between a controller and repository layer." The service layer contains business logic. In particular, it contains validation logic.

• Dependency injection: if at some point in the future, we want to change the implementation then we have to change code starting from the controller, but today if I have created DI capable services, it would save a lots of time in future as our Business logic will still remain valid.

• Dedicated service layer will give more control over the code because of abstraction, and it will be easy to maintain and expand bcause of clear seperation of concern.

• Controller will become simpler because all the business logic will now be handled by services.