Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
add comment

3 Answers

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.

share|improve this answer
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. –  Andy Nov 14 '11 at 2:14
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. –  DXM Nov 14 '11 at 3:03
If there's no view, there's no view, regardless of decoupled or not. –  Andy Nov 14 '11 at 3:18
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 Nov 14 '11 at 3:23
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)? –  DXM Nov 14 '11 at 3:51
show 1 more comment

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.

share|improve this answer
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. –  Andy Nov 14 '11 at 2:01
@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. –  Jetti Nov 14 '11 at 2:24
@Jetti that's a good point. –  Andy Nov 14 '11 at 2:27
add comment
  • 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 !

share|improve this answer
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. –  Andy Nov 14 '11 at 3:37
@Andy Youy asked for a distinction between C and V... From that perspective C handles business logic, as it handles the models. –  Yannis Rizos Nov 14 '11 at 5:03
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.