Controllers in the MVC pattern is not a replacement for Business logic layer

I have seen several demos and examples on presentations where the Controllers are more or less used as a Business logic layer and based on the definition of the MVC Pattern, that is not the correct way of using the Controller. The Controller in the MVC is not a replacement of the Business Logic Layer. The Model in the MVC is the Business Logic Layer. The Controllers purpose is to be a contract between the View and the Model, and handle user actions. Think of the Controller like the Web Form's Code-behind, the logic you put in the code-behind can sort of be added to the Controller, the benefit you get by using MVC over Web Forms is that you can now with the MVC write unit test to test "complex" presentation layer code, and it's not easy to write test against the code-behind because it's event driven.

The correct design when using the MVC would be:

Presentation (View) -> Controller -> Business Logic (Model) -> Data source

When using the Domain Driven Design, the Controller will work against the Service/Application Layer or the domain model, if we work with a old traditional n-tier architecture, the Controller will work against the Business Logic Layer.

, , , ,

2 Comments

  • Fat Model, Skinny Controller. Need to remember that.

  • We said!

    It amazes me the ranting from some about how MVC gives so much cleaner seperation of concerns than web forms, and then you see DbConnections in the controller. Basics of n-tier/layer design seem to be forgotten (or never grasped).






Comments have been disabled for this content.