Why decouple view and controller (web)?

Question

Why can't we put them in the same page, like each action paired up with its view? Not using code island, but controller code at top then view code at bottom? What are the problems with this approach?

By MVC, I am referring to frameworks such as ASP.NET MVC and Ruby on Rails, and I am under the impression that the V and C are actually the UI layer.

Answer 1

The reason why they are generally decoupled is because you want your view to use a controller in order to get at your model. But the architecture should allow you to replace one view with another one without having to change business logic (i.e. object model or how those objects are retrieved).

By not tying your controller directly to the view, later on it would me much more easier to add other functionality like import/export which can use the controller/model directly without having to rely on any UI.

Another advantage of pushing as much code as possible out of the UI is because UIs are much harder to unit test than business layer behind them. By separating as much as you can out of the view itself, you can write much more unit tests to ensure your controller/model and application logic are correct.

• Andy: For import/export, you don't need a view at all, so there's nothing to decouple with. For testing, you still can run logic test on the action/view, the only problem I see is loading the view code that you don't need to test, but you can get around that easily.
• DXM: For import/export, you don't need view at all so unless your controller is decoupled from your view, why would you want to execute view code when import/export might not even be web based. Also even with webpages, you could have more than one view into the same model (i.e. different asp page, different class), if you don't decouple your controller, you will be duplicating that code in different views.
• Andy: If there's no view, there's no view, regardless of decoupled or not.
• DXM: I thought you question was "why decouple controller from the view". If import/export needs to access controller in order to get at the object model, how can it do it without instantiating your view? Without decoupling, regardless of whether or not someone is rendering HTML, you are instantiating view code. Or do you suggest duplicating controller code inside the import/export functionality?
• DXM: Your original post: "Why can't we put them in the same page" -- so you have asp.net page which renders HTML and presents your model data. In this page you coupled your VC into one class. Now you get a requirement that your application needs to support import/export (not from this page, just in general). If a completely separate import/export logic needs access to the controller, where is it getting it from? Or are you planning to put your entire application into the same Page class? What if you want to run export offline (i.e. locally on server box outside of web server)?

Answer 2

• The controller handles bussiness logic which may change from time to time , and the View may remain unchanged , as per requirements.

• The vice versa of the above is also true.

• Designers and Developers need to be able to work on the same project independently.

A nice post: http://mashable.com/2011/11/12/designer-collaboration-strategies/

• The whole system becomes more maintainable. Solving bugs gets easier with the decoupled approach.

• Web standards with front end technologies are changing at a fast pace. Imagine a corporation deciding to migrate all the front-end technlogies to HTML5 , Dart , etc. Having a coupled View and Controller would be a nightmare !

• Andy: First and for most, business logic should be in the model. Secondly, view is full of code such as foreach and helpers, a graphic designer certainly wouldn't want to deal with that. If he wants to deal with that then he is actually a UI programmer, which the controller is part of his concern. As for HTML5, most of the HTML is constructed from a layout mechanism, HTML helpers and partial views(which are like helpers) anyway, so it doesn't really matter whether the view is coupled, you are not modifying the view itself for HTML5.
• yannis: @Andy Youy asked for a distinction between C and V... From that perspective C handles business logic, as it handles the models.

Answer 3

You don't have to separate the two of course. But if view and controller is independent then any user interface can be used. For example you can use the controller through console, sockets, web, or desktop interface. In other words, you can increase the code reuse.

• Andy: I was referring to web development, where the UI is actually the view and controller combined, so you can't really swap just the view with a new UI.
• Jetti: @Andy - sure you could, you could decide that you want to have a native iOS app and Android app for the web site that you are developing. Instead of having to do things over again, you could just make calls to your controllers and then have a separate view on the iOS/Android device, thus re-using the controller.
• Andy: @Jetti that's a good point.