Question

Let’s say I have a theoretical MVC framework that uses a ViewData object to pass data from the controller to the view. In my controller, let’s say I have some code like this (in pseudocode):

function GetClientInfo()
{
    // grab a bunch of data from the database
    var client = Database.GetClient();
    var clientOrders = Database.GetClientOrders();
    var clientWishList = Database.GetClientWishList();

    // set a bunch of variables in the ViewData object
    ViewData.set("client", client);
    ViewData.set("clientOrders", clientOrders);
    ViewData.set("clientWishList", clientWishList);

    showView("ClientHomePage");
}

And then in my ClientHomePage view, I display the data like so:

<p>Welcome back, [ViewData.get("client").FirstName]!</p>

<p>Your order history:</p>
<ul>
    [Html.ToList(ViewData.get("clientOrders")]
</ul>

<p>Your wishlist:</p>
<ul>
    [Html.ToList(ViewData.get("clientWishList")]
</ul>

This is what I understand MVC to be like (please correct me if I’m wrong). The issue I’m having here is those magic strings in the view. How does the view know what objects it can pull out of the ViewData object unless it has knowledge of what the controller is putting in there in the first place? What if someone does a refactor on one of the magic strings in the controller, but forgets to change it in the view, and gets a runtime bug instead of a compile-time error? This seems like a pretty big violation of separation of concerns to me.

This is where I’m thinking that a ViewModel might come in handy:

class ClientInfo
{
    Client client;
    List clientOrders;
    List clientWishList;
}

Then the controller creates an instance of ClientInfo and passes it to the view. The ViewModel becomes the binding contract between the controller and the view, and the view does not need to know what the controller is doing, as long as it assumes that the controller is populating the ViewModel properly. At first, I thought this was MVVM, but reading more about it, it seems like what I have in mind is more MVC-VM, since in MVVM, the controller does not exist.

My question is, what am I not understanding here about MVC vs. MVVM? Is referring to variables in the ViewData by magic strings really not that bad of an idea? And how does one insure that changes made in the controller won’t adversely affect the view?

Answer 1

Your understanding of MVC is wrong, it stands for Model View Controller but you are missing the Model in your example. This is the typed entity that gets passed back to the View to do the rendering. In ASP.Net MVC you would use typed Views that also type the Model within the View so it is checked at compile time. This eliminates the need for magic strings (second part of your question).

In MVVM you have Model View ViewModel. This is a way of binding a ViewModel directly to the UI layer via a View which is used a lot in WPF. It replaces the need for a controller and it’s generally a 1-to-1 mapping with the UI. It’s just an alternative mechanism that solves the same problem (of abstraction and seperation of concerns) but better suited to the technology.

Theres some useful info here which might help understand the difference.