Some Asp.NET MVC2 Best Practices for managing fat controllers to a Business Service layer

Question

My controllers are getting large and out of hand.

A typical controller does the following:

• It determines whether a given user has access to a given resource.
• It validates the ViewModel.
• It translates the ViewModel into the DTOModel for persistence.
• It calls repositories to update/create new objects and associated other new objects.
• It accesses data in multiple repository helper classes
• It checks whether users get notifiied.
• It calls helpers to send emails
• It logs data to the database via other repository objects
• etc...

In short, they ORCHESTRATE a lot of things. I'd like to move everything into a Services layer, but haven't really seen any implemented patterns in code samples that I like. I've looked at some of the open source projects like KiGG, Oxite, codecampserver, etc...but none of them are really solving the problem of shrinking my Controllers. I'd like to avoid passing around a lot of the HTTPContext stuff, but maybe this isn't possible.

Are there some other projects, best-practices I could be looking at? I'm building a large workflow/data input application.

Thanks for some links and suggestions

Answer 1

I don't know of any real examples to show off the top of my head, because I think I came up with my MVC apps's controller -> service -> repository layering scheme based on random questions and answers I found by browsing SO.

However, what I can give you is an example of how to organize the bullets you listed into how it would fit in the way I've structured my service layer. This may not be the best way, but this is how I'm doing my large-scale mvc app. This should give you an idea how to structure it in your own application

My service layer combines one service class per business unit. So if my application has projects, and each project has a person I would have a ProjectService class and a PersonService class.

Based upon your description of how your controllers work, my controller's actions work in the following way.

1) Get the current user's information and call the appropriate service class's authorization method. So if the user is trying to modify a project's details, I would pass the user ID and project ID to the ProjectService's AuthorizeUser method. This means if I change the way I authorize users for projects I only have to change the authorization method and not every controller.

2) Viewmodels are created, saved, and destroyed in the service layer. The service layer takes the viewmodel, validates it (raises an exception or validation result if it fails), and then converts it into a data object, which it will then pass to the repository for saving. It also requests the data object from the repository, converts it into a viewmodel and returns it down to the controller.

3) Logging of all actions occurs in the service layer. This can be automatic based on the action being presented (attempting to save an object to the db) or your controller can explicitly call the service layer to log the action.

The whole point of this is to consolidate common functionality into an easily maintainable layer. If you change how your viewmodel converts into a DTO, it is VERY easy to know where to make the change and to make it once. If you need to change your logging, user access, or even if you want to change how you retrieve certain data from the repositories it is one simple area to change rather than having to hunt down all your controllers and modify them directly.

Edit: This keeps controllers small as they only really contain a few calls to the service layer and that's it (Authorize, perform action, Show View). End Edit

Finally, the asp.net website has a tutorial for performing validation in a service layer. That tutorial can be found here.

Answer 2

You should check out this great MVCConf session about Putting Your Controllers On A Diet.