views:

106

answers:

3

Normally in the MVC Pattern, when a user clicks on a page the request would be sent ,then controller would handle the request ,then process it using the model and route it to the appropriate view.

I have read the post about the passive model and active model,but is there a possibility where the view directly interacts with the model, would that be a bi-directional relationship (i.e Model<->View) or one-directional (i.e Model->View).

Is it appropriate to have a relationship between Model and View? Well in a ASP.NET MVC project should i have a relationship between model and view, or have it independent of the model?

A: 

In Java Swing MVC is implemented as the View and Controller combined, with a View that both reads from the model and registers for events from it which effectively makes them loosely dependent on each other.

Usually web applications don't do this as the real view is rendered on the client and can't receive events from the model as easily, so in those cases the relationship only goes one way. Its certainly not a bad thing to have a relationship between the model and the view as long as the Model does not dependent directly on and view classes. In that case a dependency cycle would be set up and that harms maintenance and especially testing.

For example the way this is achieved in Swing is via a Listener interface, which the view can then implement/provide an implementation of to the model.

Paul Keeble
+2  A: 

I think it's almost always preferable to have your views be model-specific, that is, strongly-typed. Where models share related data, you can reuse partial views that are specific to that subset of data. In ASP.NET MVC, your model is -- or should be -- ignorant of the view since they only way they can interact is through a web request, which is a controller function. No you may say that you could interact through web services, but I would consider those to just be another flavor of controller. In fact, with MVC, I see very little need to develop a separate web service at all, using REST-based controller actions instead.

tvanfosson
+1 Captures the essential flavor of ASP.NET MVC.
Robert Harvey
but is there any interaction between the view and model, as far i can see is that the controller handles the request,processes using the model and depending on the action a view is generated,so the cycle isC->M->C->V (C-Controller,M-Model,V-View) ,is there any instance where it could be like M->V
The controller can pass the model, or a viewmodel, back to the view. The view can access this directly, but only to read values from the model. This would be one argument in favor of view models that don't actually persist. The model itself wouldn't typically contain any view-specific data though in practice I do sometimes insert markup into my viewmodels -- say like a grid model where one of the columns should contain a link.
tvanfosson
A: 

I always see the View as the way to present the Model. According to this point of view, the View is Model aware and in ASP.NET MVC you should inherit pages from ViewPage to avoid abusing from ViewData or castings.

With that in mind, the Model is not view aware and is just an object that is used from the view to present data to the user.

Finally, you can share the same Model from different Views, for example an XML output can share the same model as the HTML output but the views can be very different.

The cycle is more or less, Controller generates Model, passes it to the View, that shows de Model and in case there's interaction, posts the input to the Controller and the cycle starts again.

Marc Climent