I have recently seen a .NET MVC solution in which the markup in the .aspx views which appear to have a Controller as their model i.e the controller seems to be providing the data for the view, and the .ascx user controls they contain use a separate model. I'm new to MVC and I wanted to find out about a few things I'm not clear on.
An example of how the code is implemented:
UserDetails.aspx view has markup that shows it's using the UserDetailsController.cs as the model. It contains RenderPartial("User_Details.ascx", UserDetailsModel) and passes it the UserDetailsModel.
Is this the standard/correct way of implementing MVC? Or just one way to implement it?
I also noticed that the classes used as Models appear to be Service classes that have [DataMember] and [DataContract] attributes on the class name and properties – what is the advantage of this implementation?
Best Answer
Based upon the limited description so far, the best answer I can give is "maybe."
Here's my partial take on MVC, which generally aligns with others' takes. But there's always bones of contention to be had. I would recommend Martin Fowler's articles as a good starting point with MVC and the other MVx variants.
The View should not be aware of the Model; it only knows what the Controller feeds it.
The Controller is more than welcome to directly pass a data structure from the Model to the View. But the Controller is on the hook to maintain that contract with the View if the Model should change.
In other words, the Controller may retrieve a List of users from the Model and then pass that List directly to the View. In this case, the structures magically aligned and all three layers are able to utilize the same (or similar) structure.
Should the View need additional details later on, then the Controller will be responsible for accessing the Model as necessary in order to provide those additional details back to the View.