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).


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.


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