Who's responsible for the next View?

Question

In an archetypical MVC architectur, where does the logic go, that determines which view to show next?

The assumption is some kind of app with several views (windows) that may or may not be visible at different times, depending on user actions. For instance, sometimes the application may need the user to fill out a form with additional details, other times it may not. Is it the controllers responsibility to ask for a specifik view to become visible?

Am I thinking about this wrong? Maybe the controller determines which other controller should assume control, and the view just updates according to which controller is active?

I'm confused.

Answer 1

What you are looking for is an Application Workflow Manager, or Application Controller.

http://martinfowler.com/eaaCatalog/applicationController.html

Your controller should ask the Application Controller what to do next. This avoids hard-coding in the navigation, and allows for multiple situations.

Say for example, you have a contacts list, and hit the create button, to create a new contact. When save is completed successfully, the create form should go away, and you should see the contact list again.

However, say you are creating a contact as part of a quote. After the contact is created, you don't want to go back to the contact list, you want to go back to the order form.

You could use a switch statement to determine what to do next, or a state machine, or something like:

Spring Web Flow http://www.springsource.org/spring-web-flow

Windows Workflow Foundation http://msdn.microsoft.com/en-us/netframework/aa663328

Answer 2

The controller. The controller view is not a one to one relationship. A controller can have many views (think of a wizard type situation). If this is out of your control, the controller's view can actually be another controller, this controller responsible for your multiple views.

Answer 3

The controller is the boss in the MVC pattern. It is responsible for delegation whilst doing minimal work itself ;).

A request comes in and the boss looks at it and thinks "Hrm... there is a lot of work involved here. I need to get some data from my database. Luckily I have subordinates! Hey model, come over here. I need you to go off and get all the information form the DAL."

Think of the model as a developer. Does all the real hard work, gets his hands dirty, and without the model, the whole system would come crashing down. It goes off and does all the business and domain logic. It then runs back to the boss and hands in all his hard work. "Here you go gov".

The boss then needs to return the data to the user. Again - too much work for him. So he gets a stupid junior dev aka the view to do it. (Not all juniors are stupid, but it works for this example!). The view knows nothing. It doesn't care how the data came to be, just that it's there and works. The boss may make some minor alterations to the data as we don't want the view having more responsibility than it needs, then the view goes off and displays the data. Depending on the work load, the boss may recruit multiple views for the job.

Basically the controller controls all flow in the MVC pattern. It decides what models to call, and what views to render, and what data from the model to pass to the view (ViewModels).

You can call other controllers from a controller. If you have a search box on your homepage for example, when a user hits search, it can call the index function on the search controller. In my metaphor above, it would be akin to one department passing a job to another department. Then this whole process starts again, with the boss recruiting the staff he needs for the current request.