Using MVC, how do I design the view so that it does not require knowledge of the variables being set by the controller?

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 i开发者_如何学Gos 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?

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.

Best approach to use strongly typed views

Models:

public class ContentPage
{
    public string Title { get; set; }
    public string Description { get; set; }
}

public class ContentPagesModel
{
    public ContentPage GetAboutPage()
    {
        var page = new ContentPage();
        page.Title = "About us";
        page.Description = "This page introduces us";

        return page;
    }
}

Controller:

public ActionResult About()
{
    var model = new ContentPagesModel();
    var page = model.GetAboutPage();

    return View(page);
}

View:

@model Experiments.AspNetMvc3NewFeatures.Razor.Models.ContentPage
@{
    View.Title = Model.Title;
} 

<h2>About</h2>
<p>
     @Model.Description
</p>

for more detail check out here

I case of using string as keys of ViewData - yes, it will be a lot of exceptions if someone will refactor code.

It sounds like your understanding of MVC is very old, probably based on MVC 1. Things have changed tremendously in the last couple of years.

Now we have strongly typed view models, and we have the ability to use expressions in the view, which by default aren't compile-time validated, but they can be for debug purposes (though it slows down the build a great deal).

What's more, we don't pass model data through ViewDate anymore (well, not directly anyways.. it's still passed that way but the framework hides it).