In ‘SOLID’ the ‘I’ stands for Interface Segregation. The whole idea of this principle is to split large interfaces into smaller ones, more modular. In MVC service would normally have an interface that controller would rely upon. You don’t want your controllers to know about concrete implementation of that service. Therefore, a bunch of services with one or two methods is a good thing to have.

Services normally return DTOs in large applications or domain models directly in smaller applications. DTOs normally means more work, but better separation of concerns. The typical flow is:

• Controller calls service
• Service returns an object (be it a DTO, domain model or something else)
• Controller maps DTO/domain model to a view model

Mapping can be done manually, but most developers prefer to use auto mapping framework such as Automapper because we don’t like writing plumbing code and we can be quite lazy 🙂

http://en.wikipedia.org/wiki/Interface_segregation_principle

https://github.com/AutoMapper/AutoMapper

One of many discussions on stackoverflow regarding use of DTOs and domain models: https://stackoverflow.com/questions/2680071/dto-or-domain-model-object-in-the-view-layer

In MVC the Model, is not just a DTO or set of Managers/Services it is meant to represent the concepts your application is modelling. You can think of this as the entire domain or the business logic including state and behaviours. Now given that we know that the purpose of the controller becomes a bit clearer. It’s job is simply to translate commands onto the Model and the result back onto the views. This is usually done in the form of ViewModels which are different but often confused with the Model in MVC.

If you don’t have a well defined Model then you may have gotten to the point where most of that logic now resides in the Controllers themselves. At this point in order to start reducing the size of your controllers you can start to pull this logic back into manager or service objects. These services typically return and operate on DTO/Entity like objects. Then the controller becomes the mapping layer between these services and the View Models. For a few good tips on mapping have a look at this article Friends don’t let friends use AutoMapper.

As for your questions, the first one depends a lot on your applications. You’ll need to do refactoring along the way which should become more apparent once you’ve removed the logic from your controllers. As for testing there is no problem instantiate models inside services however if you find it testing difficult it’s probably just a sign you need to break up the service into smaller parts each with a single responsibility.

Controllers should only contain calls to the model (where the business logic happens) and based on those calls assign data for the view (objects of information or error messages) therefore controllers will be quite small even for a very complex page, if the controller still gets very big you should think that maybe that page should be expanded into more pages.

Still the model can be quite big… the solution I found was having a variable inside the controller that tells what model to load and for specific tasks I load the specific model.

Try to obey the model-view-controller model clean like this:

• view: displays data
• controller: collects userinput, asks model for the requested data and sends it back to the view
• model: interacts with database and performs logical actions to prepare information

I find services really helpful to perform logic that may need to perform by more than one controller or that is just not specific enough to be part of the controller, besides the fact that it stops my controllers of getting too big and hard to read…

I personally disagree with ‘aaa’ when he says that “model (where the bussiness logic happends)” since thats the whole reason you have controllers, in my opinion models need to be simple data abstractors so controller can perform the needed task; again services should not get involved into data abstraction task…

just saying yo….