CODEWITHSUNDEEP
c#model-view-controllerrepository-patterncastle-monorail
John Polling
John Polling

Reputation: 2282

Service Layers and Repositories

I've been using MVC frameworks for a short while now and I really like how the concerns are separated out. I've got into a bad habit of letting the controllers do quite a bit of work. So I'm really looking for some advice.

When I first started using MVC I quite often had the controller doing manipulation on the models after database work had been done. I knew this was bad so moved that work into the models. However I'm not happy with that as I want my models to be very learn.

I've done a bit of reading and I see that people are keeping their controllers and models lean by having a service layer, which I like the look of.

I'm just trying to understand how a service layer and repository should all work together. Here are my assumptions, can you please let me know if this is a good way of working?

  1. The controller can call the repository directly if no manipulation needs to be done on the data and as such a service layer does not need to get involved
  2. Once any work needs to be done to data (business logic) then this should be done in the service layer and the controller will make a simple call to the service layer as and when required
  3. Once a service has done it's business logic it will then use the repository as necessary (if data needs to be persisted).
  4. Models ideally should be kept lean, ideally actings as nothing more than DTOs
  5. Validation of data will be done within the models (using MonoRail validation attributes). I appreciate not even one likes polluting their models with lots of attributes, but that is a different discussion. I like the benefit of MonoRail's validation attributes for the automatic jQuery validation in the UI.

I'm trying to turn all my code around to the single responsibility principle, hence trying to sort out my coding practices.

Thanks

Upvotes: 48

Views: 8561

Answers (3)

Mandeep Janjua
Mandeep Janjua

Reputation: 16195

This video gives great insight into how to organize your asp.net MVC solution and addressing separation of concerns, and better testability. Hopefully it will help someone else also. I learned some good stuff from it.

Upvotes: 7

BigJump
BigJump

Reputation: 16419

Ian Cooper has just written a blog post called The Fat Controller on just this subject.

Upvotes: 6

gcores
gcores

Reputation: 12656

First, there is no set of rules that's going to work in every situation. How you model you're application depends a lot on the type and complexity of the project. Having said that, here are some ideas:

  1. Nothing wrong with calling the repository from a controller. Just make sure the controller does not contain business logic.
  2. The service takes care of (some) business logic and uses other services to do so. The repository is a type of service, there's nothing wrong with calling it from a service.
  3. The model should contain business logic, actually you should always try to put it in the model first. If you need external data to perform that business logic (from another model or from the repository) then you should create a service.
  4. Nothing wrong with validation in the models. Using attributes or not is a question of taste (if you like it then it's good). Move the validation outside of the model if it gets too complex (create a external set of rules).

Most important, do what feels right (that's usually the right answer).

Upvotes: 26

Related Questions