asp.netmvcruby-on-railsweb-development
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.
First I think is best talk about what is MVC Architecture and then go further into the way you are currently programming.
The MVC Architecture is way to organize the workflow inside a sotfware sistem, think about it as a layered way to implement system behaviour. This layers are:
Model: Represents your Data Model, its the system core where all information related to it should be localized. So for example: if you are going to desing a Game you'll need Players, Rules, Obstacles, and some logic related to the interactions of this elements such as : Players should be able to sort Obstacles when some set of Rules apply.
The Model is the first think you should think off because its going to be the center of your applications.
Controller: This is where the magic happens and where the Layered Architecture meets the Object Oriented Paradigm it was intended to use. Here is where you implement how does the system reacts when some application user request something about the app vai the user interface.
The Controller should be able to handle the Model Objects, do operations with them to achieve what the user requested and then delegate the result to the corresponding View Layer to render it back to our user.
View: This is the Start and End Point of User interactions. Here is where you define how users interact with the application. Nowadays is quite common users try to access, for example, web applications from different kinds of media such as: Mobile Phones, Tables, Pcs, Laptops, etc.
Generally each techonologie needs a diferent language to create the view, so imagine that your Data Model and the way that model interacts and how you render that interactions is all hardcoded, there is absolutely no way to reuse your code in a way that is not CopyPaste. The result is code that smells and lots of time wasted adapting the HOLE sysmte.
The virtude of having the View in a separated layer, allow us to work independently from the Model we are currently working on. We only need to know how we should render the list of objects the controller is sendng us. How did he generated it is completly trivial
So , finally we got an independet Model that could be adapted as we see fit according to our current needs (today i need to handle a Monouser Game with no rules, tomorrow i whan to play with friends and now its Multiuser, and so on) that not depends on how are we going to render it to the user. Then, a Controller that captures users request that came from a view , process Model Objects, and then gives the information back to the View to render it.
Back to the first question you asked: Like you can see (i hope) MVC is a WAY to do things and not a TECHNOLOGIE to create software. You could use your java Servlets, and implement a MVC Achitecture under it.
Here is a Q&A example site using a MVC Architecture to clarify a little
The controller prepares data which will further be passed to the view for rendering / displaying. It also accepts user input data through a publish-subscribe mechanism or similar. Check out the first diagram on Wikipedia or Martin Fowler's website for more information about MVC.
if the view is expecting data from the controller, then they're effectively tied together as a (controller, view) pair.
While a view generally accepts data, in most MVC frameworks, it does not depend on specific controllers. Exceptions are, for instance, the JavaServer Faces family. Generally speaking, frameworks like Rails, Django or Spring MVC allow you to decouple views from controllers by passing data (the context, commonly a map/dictionary/bag) to a view (where a view is an implementation of the template view pattern).
Does the answer change when you have the concept of a strongly-typed view (like in ASP.NET MVC) or not?
Whether or not your programming language is strongly-typed has no influence on the way your are organizing your application.
Best Answer
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.