I’ve been working on an open-source client-side MVC library for ASP.NET 2.0 which you might like to check out if the idea appeals. See blog.codeville.net/…/
/>There are some quick demos on the site which show the source code.

If you want to invent your own policy entirely, you can also just implement the IController interface:

interface IController
{
public void Execute(IHttpContext context, RouteData data);
}

This Execute method takes an interface based version of the HttpRequest/Response/Server/Application/Session intrinsics (enabling easy mocking) as a parameter, as well as the tokenized URL route information (based on your route table). If you want to build a completely different controller abstraction you could use this to implement whatever policy you want.

Hope this helps,

Scott

-Jame

Consider the scenario where you are using property dependency injection on your controller, and have a public IDataRepository property that you expose from your controller.

For clean separation of concerns you want to make sure that your data repository isn’t directly passed to your view. If all properties were passed automatically you could inadvertainly have your view gain access to this.

Having said that – if you do want to send all properties of your controller to the view, just pass a “this” reference when rendering the view:

public class ProductsController : Controller
{
public string Message { get; set; }

[ControllerAction]
public void Edit(int id)
{
this.Message = “Hi James”;

RenderView(”Edit”, this);
}
}

Alternatively, you could create a JamesController base class that overrides the default RenderView virtual method and does this by default:

public class JamesController : Controller
{
protected override RenderView(string viewName) {
RenderView(viewName, this);
}
}

You could then just write your controller like below and have the behavior you want:

public class ProductsController : JamesController
{
public string Message { get; set; }

[ControllerAction]
public void Edit(int id)
{
this.Message = “Hi James”;

RenderView(”Edit”);
}
}

Hope this helps,

Scott

-James

Besides going against the spirit of seperation of concern it also means you could expose sensitive data where you have re-used a view not realising one of the variables the view uses is not sensitive on one controller but sensitive on another.

[)amien

/Magnus

What does everyone else think?

-James

By default the Controller base class has a ViewData collection that you can use to add just the variables you want to the view. Alternatively, you can pass the viewdata object directly as part of the RenderView method:

RenderView(”Edit”, myProduct);

The reason we currently don’t by default send all instance variables was that in app-building we found that you often had instance data that was controller specific (or action specific) and that you didn’t necessarily want to send all of this to each view. It felt a little unclean to automatically send everything to the view. It is something we’ll ceretainly be interested in feedback on with the first preview. As I mentioned above – it is only about 5 lines of code to change it (so if people prefer it different we can definitely change it).

Thanks,

Scott

-James