Simon Ince's Blog : ASP.NET MVC Framework

Virtual Earth meets MVC

simonince — Wed, 29 Oct 2008 23:10:00 GMT

Something I do quite a bit with customers is to help them understand and use Virtual Earth... plus I’ve been doing some overviews of the beta of the ASP.NET MVC Framework, so it seemed a great combination. How would you best combine them?

Note: This post is based on the October 2008 Beta of the ASP.NET MVC Framework... it will likely break before v1.0.

ASP.NET WebForms Approach

When hosting Virtual Earth in a WebForms solution, I use the following rough architecture;

The WCF service has two jobs; it provides lists of points to display on the map, and it provides additional information to render about each point if the user clicks a “more information” link. This info is usually shredded manually into the HTML by custom script.

There are a few problems with this;

1. You cannot currently use the <ASP:ScriptManager> control in ASP.NET MVC.

2. I want to minimize the amount of custom AJAX I write – the MVC framework has helpers that I want to use.

3. I suspect some of the partial rendering capabilities of the MVC framework will be useful.

An ASP.NET MVC Approach

My MVC approach is slightly different. On face value it looks complex, but in reality the implementation is very straightforward;

Well let’s get going. Hosting Virtual Earth is easy, so we’ll get the basics in place and see what we’ve got. Firstly I need to import the Virtual Earth controls with a simple script tag;

Note I’m using version 6 – if a new version is out when you read this, you may need to update this link and revisit some of the code.

Now I’ll create a “div” to hold the map in my Master Page (do excuse some of the terrible CSS and layout in this post, I’ve just not got time to beautify my code today!);

<div id="LocationsMap"

style="position: relative; width: 100%; height: 100%;">

</div>

Next, I edit the body tag to cause the map to load with the page;

... and add a simple JavaScript function called DisplayMap that does the work. The core of this is creating the VEMap control, specifying the name of my “div”, as follows – for the rest, check out the code download;

map = new VEMap('LocationsMap');

This is all on my master page, and we’ve now got enough code to display a map the user can navigate around. To let us do this, simply add an Action to a Controller that returns a View(), which in turn is using the master page we’ve just defined;

public ActionResult Display()

{

return View();

}

Problem 1: No ScriptManager

The next thing I need to do is call my WCF service to fetch a list of “waypoints” to display on my map. But ASP.NET MVC isn’t compatible with the ScriptManager control. There are a few options here – the first is a codeplex project named ajaxmvc. What I’ve found to be a simpler solution, though, is to manually create the script reference that the ScriptManager creates for you;

I use the MVC framework’s “Url.Content” helper method to map the URL to my service, and append “/js” to ask the service for JavaScript proxy script. This now means I can call my service using the generated proxy;

function GetWayPoints() {

MvcWithVE.Services.IWaypointService.GetWaypoints(

SuccessCallback, FailureCallback);

}

The callback does the job of adding each waypoint to the map. Check out the code download to see how, but there is an important bit coming up...

Problem 2: Loading More Information

What I want to do next is load in more information about a selected waypoint, and display it in a panel beside the map. This just sounds ideal for the MVC framework’s partial rendering capabilities. If I can return a fragment of HTML and push it into the page, I’ll have saved loads of time.

Well, the Ajax.ActionLink helper method is useful here. I can provide it with a Controller and Action to call, and the ID of an HTML element to put the returned fragment into.

So let’s create a <span> to hold our fragment containing further information;

<span id="details">Please select a Waypoint...</span>

How do I get Virtual Earth to give me a “more information” link that populates this span then? The solution is two-fold. Firstly, I like to create a template for what will be displayed when I hover over a pin on the map;

<div>

<p>

<b>{{Title}}</b>

</p>

<p>

This Waypoint is located at {{Latitude}} latitude,

{{Longitude}} longitude. For more information

<%= Ajax.ActionLink("click here...", "WaypointDetails",

new { id = "{{Id}}" },

new AjaxOptions { UpdateTargetId="details" })%>

</p>

</div>

</span>

This is a very simple bit of HTML, with markers in place (e.g. “{{Title}}”) that I can use to replace with real data. I guess I could put it in a separate User Control and use RenderPartial to pull it in if I wanted to. The cunning bit is that I also embed an Ajax.ActionLink call, providing a placeholder named {{Id}} for the “id” parameter to the WaypointDetails action. I’ve also specified the UpdateTargetId parameter to AjaxOptions as “details”, the name of the span I created above.

Now consider the code I use to add a pin to the map;

// Adds a waypoint to the map

function AddPoint(id, name, latitude, longitude)

{

// create the pin

var pin = new VEShape(VEShapeType.Pushpin,

new VELatLong(latitude, longitude));

// load in the template for the pin

var content = document.getElementById('pinTemplate').innerHTML;

// replace fields with values

content = content.replace('{{Title}}', name);

content = content.replace('{{Latitude}}', latitude);

content = content.replace('{{Longitude}}', longitude);

content = content.replace(escape('{{Id}}'), id);

// set the pin's content to the parsed template

pin.SetDescription(content);

// enable the pin's icon

pin.ShowIcon();

// add it to the map

map.AddShape(pin);

}

I load in my template and replace the fields with real data. The one thing that might trip you up is that I must URL-encode the “{{Id}}” placeholder using the JavaScript “escape” function in order for the replace method to match it, as the Ajax.ActionLink will have URL-encoded it already. You can see this by looking at the HTML source for a rendered web page, and note that the link has become;

... href="http://blogs.msdn.com/Map/WaypointDetails/%7B%7BId%7D%7D" ...

We then use the pin.SetDescription call to ask Virtual Earth to display this whole fragment when a pin is hovered over.

The very last piece of the puzzle is that we need an Action named “WaypointDetails” that the Ajax.ActionLink method is pointing at. This is really simple in my case, as I’m just using LINQ-to-SQL to pull back some data;

public ActionResult WaypointDetails(int id)

{

using (WaypointDataContext db = new WaypointDataContext())

{

Waypoint point = db.Waypoints.Single(w => w.Id == id);

return View(point);

}

Of course, I have a matching View named “WaypointDetails.ascx”, which looks like this;

<tr>

<th>Title</th>

</tr>

<tr>

<th>Latitude</th>

</tr>

</table>

To round off the solution, I’ve added a link to call GetWaypoints() when the user clicks on it, tweaked the routing to default to my new Controller, and deleted some of the stuff the MVC project template gives me by default that I don’t need.

Phew!

OK, I’ve been through this really quickly because I think the code is pretty self-explanatory, but I hope you’ve enjoyed seeing how easy this is. What is more, it gives you a great way to separate responsibilities for rendering the host page, rendering fragments, hosting your logic, fetching data, and more.

The end result is pretty cool, I think! Like it?

More MVC vs MVP

simonince — Tue, 17 Jun 2008 12:23:00 GMT

Phil Haack, currently famous for working on the ASP.NET MVC Framework, has just blogged a great article comparing Model View Controller and Model View Presenter. I’d highly recommend giving it a read. There is also an old post of mine here comparing MVC and MVP within the context of the Web Client Software Factory and the (as it was then) recently announced ASP.NET MVC Framework.

This seems to be a hot topic at the moment, as people are trying to understand which pattern suits them best.

I would strongly recommend giving this some thought, but remember that patterns are not everything – what also counts is the wider framework that you select. Whether that is classic “vanilla” WebForms, the ASP.NET MVC Framework, the WCSF, any number of open source frameworks, or your own in-house framework; each of these when combined with the patterns they implement bring different levels of accelerated development, testability of UI classes, dictated solution structure, or assistance beyond the UI patterns.

What is important is to pick an approach and build on it... but then you’ll be bored of me saying that by now if you read this blog regularly!

MVC and Unity

simonince — Thu, 14 Feb 2008 12:54:00 GMT

Well it’s a week of news;

Scott Guthrie has posted an update on the ASP.NET MVC Framework roadmap, and the Unity Dependency Injection Framework has just released a CTP (via Grigori)...

What’s more, David Hayden is first out of the gate with a nice brief post on combining the two...

Multiple Views with MVC

simonince — Mon, 04 Feb 2008 19:00:00 GMT

In my previous two posts (one and two) discussing the use of AJAX within an ASP.NET MVC Framework application, I’ve tried to demonstrate some ways that the framework can be extended or modified. In keeping with this approach, I thought I’d show how it is possible to change the way that Views are resolved using a “View Factory”. Again, this is much more about the demonstration than the subject matter: i.e. AJAX is incidental to seeing how to use the MVC framework. Please read the previous posts if you want to follow the specific example I’m using here.

Usual disclaimers apply – and this is based on pre-release software that will no doubt change, and therefore this post will likely become outdated.

The key to this post, then, is that instead of using a single View that behaves differently according to whether or not AJAX is supported, I want to have two separate Views – one for AJAX, one for without.

To achieve this is pretty simple.

1. We need to create our own implementation of IViewFactory. This is responsible for locating and creating an instance of an IView (which both ViewPage and ViewUserControl implement).

2. To “inject” (all you DI fans excuse me borrowing the term without using a DI framework) our new View Factory into every Controller we are going to create our own IControllerFactory implementation.

3. We need to configure the framework to use our new Controller Factory.

4. Finally we can create two Views – an AJAX version and a pure HTML version.

Easy huh? Lets fly through the implementation of each of these...

View Factory

To minimise my effort I’ve sub-classed the WebFormViewFactory;

public class AjaxViewFactory : WebFormViewFactory

{

protected override IView CreateView(

ControllerContext controllerContext,

string viewName,

string masterName, object viewData)

{

string mode = controllerContext.RouteData.Values["mode"] as string;

IView view = null;

try

{

view = base.CreateView(controllerContext, viewName + "-" + mode,

masterName, viewData);

}

catch (InvalidOperationException)

{

if (view == null)

view = base.CreateView(controllerContext, viewName,

masterName, viewData);

else

throw;

}

return view;

}

Now I should imagine you’re all screaming now (and no, not because I don’t check “mode” isn’t null – this is demo code J). Truth is, I’d like the implementation of this to be different – perhaps by overriding WebFormViewFactory.GetTypeFromName, but some of the framework’s members are private and not virtual... hence my hack.

Basically all we do here is append the value of “mode” (which is “ajax” or “html”) to the end of the view name. So a request for a “List” view will return “List-ajax” or “List-html”. If we can’t find a View by this name, we fall back to the version without a suffix. [Important: The catching of exceptions in this way as effectively anticipated business logic is strongly not recommended – this is the ugly code I was referring to. This is hard to maintain and could easily become a performance hit if you have lots of Views without a suffix, so in production code I would put the effort in to handle this properly – I haven’t here simply to save space and complexity]. I then reuse the standard functionality of the WebFormViewFactory to do the hard work of creating an instance.

This should make it pretty obvious how you could change this behaviour to your heart’s content. There is no reason why you couldn’t completely remove any remnant of the WebFormViewFactory – as long as you return an instance of an IView you’re away!

Controller Factory

The Controller Factory is almost embarrassingly simple;

public class AjaxControllerFactory : IControllerFactory

{

public IController CreateController(RequestContext context,

Type controllerType)

{

Controller controller =

(Controller)Activator.CreateInstance(controllerType);

controller.ViewFactory = new AjaxViewFactory();

return controller;

}

All we do here is create a new instance of our Controller, and make sure we set the View Factory to be an instance of our new class. The key to getting our new Controller Factory to be used instead of the default factory is a single call in the Application_Start event of Global.asax;

ControllerBuilder.Current.SetDefaultControllerFactory(

typeof(AjaxControllerFactory));

And that’s it.

Views

To get my Views working I took the existing “People.aspx” View, and copied it twice to “People-ajax.aspx” and “People-html.aspx”. I then removed the if statement below;

<% if (ViewData.EnableAjax)

{ %>

<%= Ajax.UpdateRegionLink<AjaxSampleController>(d =>

d.UpdatePerson(emp.Id), "Individual", emp.Name) %>

<%}

else

{ %>

<%= Html.ActionLink(emp.Name, new { action = "ViewPeople",

id = emp.Id })%>

<% } %>

... and instead left the relevant section in each View – i.e. the Ajax call in the “–ajax” view, and Html call in “-html” view.

Round-up

Well folks, that’s all. I hope that’s a pretty clear demonstration of how easy it is to plug into the MVC pipeline. If you’re interested in IViewFactory specifically, head on over to MVCContrib – looks like some View Factories are in the code base.

To AJAX, or not to AJAX - rendering in ASP.NET MVC

simonince — Mon, 28 Jan 2008 11:52:00 GMT

One issue I have had on numerous customer engagements is that there has been a good opportunity to use AJAX functionality, but I need to support a significant user base that cannot use Javascript. Typically this is to meet accessibility requirements (and laws), and the users in question tend to be using screen readers or similar software. Ensuring a good experience for both of these groups of users is essential.

There are ways to detect browser settings, but a) sometimes these do not give an accurate indication as to the user’s preference, depending on the organisation’s desktop configuration, and b) I want to use this to demonstrate something! So how could we use the ASP.NET MVC framework to make our life easier?

First of all, read my thoughts on “Ajax support in ASP.NET MVC”, as I’ll be using the example to demonstrate my approach. Now let’s define what we need to be able to do.

1. Detect whether the user wishes to enable AJAX functionality

2. If the user will permit AJAX, use javascript to update the employee details user control contents with a partial page rendering call to the server.

3. If the user will not permit AJAX, re-render the entire page, but selecting the correct Employee (rather than defaulting to the first in the list as my original demo does).

Detecting preference from the URL

I decided to use Routing to determine which version of a page a user wants to view. I chose the following two URL schemes;

http://mysite/ajax/Demo/ViewPeople

http://mysite/html/Demo/ViewPeople

When “ajax” is in the URL, we will enable javascript functionality, and when “html” is in its place, we will disable javascript functionality. I think this is a really clean way of directing requests, and letting users bookmark different versions of the site – even though, as we will see, they could be running the same code base.

The key to achieving this is to add new route definitions to the top of the Application_Start event in Global.asax. My first thought was to do something as follows;

RouteTable.Routes.Add(new Route

{

Url = "ajax/[controller]/[action]/[id]",

Defaults = new { action="Index", id=(int?)null, ajax="Yes" },

RouteHandler = typeof(MvcRouteHandler)

});

RouteTable.Routes.Add(new Route

{

Url = "html/[controller]/[action]/[id]",

Defaults = new { action="Index", id=(int?)null, ajax="No" },

RouteHandler = typeof(MvcRouteHandler)

});

The key here is that nowhere in the URL is the “ajax” member found, but I can declare it with a default and if that route is matched, “ajax” will receive a value of Yes or No and be passed into the destination Action (either as a named method parameter, or as an entry in the RouteData.Values collection).

[One important point to note is that I would have liked to have defined the “ajax” as a Boolean, but I believe the CTP handles Booleans incorrectly, so I’ve resorted to a string for now.]

This is a useful technique, but in this case we can do something even simpler;

RouteTable.Routes.Add(new Route

{

Url = "[mode]/[controller]/[action]/[id]",

Defaults = new { action = "Index", id = (int?)null },

Validation = new { mode = "^(ajax|html)$" },

RouteHandler = typeof(MvcRouteHandler)

});

This route will match requests that start “/ajax/” or “/html/”, and then do the usual Controller and Action matching. The value of this “mode” parameter will be passed to the Action in the same way as the “ajax” parameter in the option above. Key to this approach is the validation line – which prevents “/madeupvalue/Controller/Action/1” from matching this route – the mode must be “ajax” or “html”.

Note that I have also applied the “mode” parameter to the “Default.aspx” rule. This means that on entering the site the user will always have to specify which version they require, and that will be passed on throughout all the links as the default. There are other ways to work this – such as a menu page prompting the user, but I chose the simplest example.

Creating a dual purpose entry point

For my approach, we must now create an Action that can render the whole page, including the user control, either on a user’s first visit (and so defaulting to the first Employee in the list) or when a non-AJAX user requests details on a specific Employee. I’ve come up with the following (refer to my previous AJAX post for the original code);

[ControllerAction]

public void ViewPeople(int? id, string mode)

{

DbDataContext db = new DbDataContext();

List<Employee> all =

(from e in db.Employees select e).ToList<Employee>();

EmployeeSet set = new EmployeeSet();

set.Employees = all;

if (id.HasValue)

{

set.SelectedEmployee = (from e in db.Employees

where e.Id == id.Value

select e).SingleOrDefault<Employee>();

}

else

{

// default to first employee

set.SelectedEmployee = all[0];

}

set.EnableAjax = (String.Compare(mode, "ajax", true) == 0);

RenderView("People", set);

}

The key here is that the “id” parameter is nullable. Therefore, if an “id” is specified, the first Employee is used as the selected one, otherwise the Employee who’s Identifier is specified is used. There we go – one dual purpose Action!

Note also that the “mode” parameter is used to set a new property on the EmployeeSet Model class indicating whether AJAX is enabled or not – we will see this in action in the view later.

No change is needed to the UpdatePerson action, as this will always be used by the AJAX-enabled view.

Tweaking the View

The last step is to update our view to behave differently according to the user’s preference. We’ve already passed this preference into the view using the model data, so it should be pretty straightforward. All we need to do is conditionally replace our AJAX link builder with a fixed HTML link to our new dual-purpose view.

Trimming out the irrelevant bits and bobs, my new view looks like this;

<table>

<tr>

</tr>

<% foreach (Employee emp in ViewData.Employees)

{

<tr>

<td>

<% if (ViewData.EnableAjax)

{ %>

<%= Ajax.UpdateRegionLink<AjaxSampleController>(d => d.UpdatePerson(emp.Id), "Individual", emp.Name) %>

<%}

else

{ %>

<%= Html.ActionLink(emp.Name, new { action = "ViewPeople", id = emp.Id })%>

<% } %>

</td>

</tr>

} %>

<tr>

</tr>

</table>

<prs:PersonInfo runat="server" ViewDataKey="SelectedEmployee" />

</div>

You’ll notice that I’m using the Html.ActionLink method – and also that I have not specified the mode of “html” in the parameters; this is because if we’re viewing the HTML version, it will default to the current request’s value for us.

And that’s it – we now have a view that will work for both javascript and non-javascript users, governed by their choice of URL, with only one code base to maintain. I’m sure this could be greatly improved with some tidying and tweaking, but I hope this has illustrated how powerful Routing can be when used in conjunction with the rest of the framework.

Other Approaches

It is worth pointing out that we could do this in many ways – we could have two separate Views (“PeopleHtml” and “PeopleAjax” for example), and write our own IViewFactory, which gets plugged in by a custom IControllerFactory... and I’m sure there are many other ways. I love how flexible this framework is – there always seems to be a couple of options.

AJAX support in the ASP.NET MVC Framework

simonince — Wed, 23 Jan 2008 21:29:00 GMT

[Edit: Note that this post is based on a pre-release, and now out of date CTP of the MVC framework. I'd suggest you use it to understand concepts, but look elsewhere now if you're after up to date facts. I've recently added a post about Virtual Earth and the MVC framework that includes the use of some AJAX - read it here]

I’ve been curious about how AJAX support might be added to the ASP.NET MVC Framework. Specifically I could see huge potential in defining portions of pages (views) as User Controls inheriting from System.Web.Mvc.ViewUserControl<T>. This allows the region of the page to be rendered either inline in another view, or on its own, and therefore means that an initial page can be rendered, yet the User Control section can be updated using AJAX calls. What enables this to work is the fact that the Controller.RenderView method in the framework can handle both ViewPage and ViewUserControl derived UI elements.

So I decided to write some code to enable me to play with this. Bear in mind that this is purely flaky experimental code – I’m sure the product group will do a far better job than this sample, but the point of this post is to demonstrate the kind of things you can achieve with the MVC framework, not to produce a product! If you are interested in AJAX support in the framework, I recommend heading over to Nikhil’s blog for a quick read.

This post is actually incidental to the real reason I was writing some code, to demonstrate a different technique – which will be revealed in a future blog post in the not-too-distant future.

As usual the code included conveys no warranties etc, and has been written against the December 2007 CTP – and therefore will likely be superseded or simply won’t work on later releases J.

Anyway, to meet my needs I’ve done a number of things;

1. Created a simple Employee table, and used LINQ-to-SQL to get at the data easily.

2. Written a Controller with two actions – one to render a full initial page, and one to render just the portion of the page contained within the user control.

3. Created two views – one full page (that includes the user control), and one user control.

4. Created an extension method for the AjaxHelper type that renders a link to update a user control’s content.

Initial Setup

The code for the controller is very simple. I’ve created a simple Model entity to hold a list of Employee entities, plus a selected one;

public class EmployeeSet

{

public List<Employee> Employees { get; set; }

public Employee SelectedEmployee { get; set; }

}

There is then an action that renders a whole view, passing in the EmployeeSet entity;

[ControllerAction]

public void ViewPeople()

{

DbDataContext db = new DbDataContext();

List<Employee> all = (from e in db.Employees

select e).ToList<Employee>();

EmployeeSet set = new EmployeeSet();

set.Employees = all;

// by default, show the first employee in the user control

set.SelectedEmployee = all[0];

RenderView("People", set);

}

The key to this working is of course the “People” view, for which the first version looks very simple indeed;

<asp:Content ID="Content1"

ContentPlaceHolderID="MainContentPlaceHolder"

runat="server">

<table>

<tr>

</tr>

<% foreach (Employee emp in ViewData.Employees)

{

<tr>

<td>

<%= emp.Name %>

</td>

</tr>

}

</table>

<prs:PersonInfo ID="PersonInfo1"

runat="server"

ViewDataKey="SelectedEmployee" />

</div>

</asp:Content>

Of course, this ASPX view inherits from ViewPage<EmployeeSet> to enable me to use strongly typed access to the model data. Perhaps the next most significant point is the use of the User Control – note that I have omitted the Register directive in this snippet, but it does need to be there. I specify the name of the property on the View Data that I wish to pass to the User Control in the ViewDataKey property. This ensures that the currently selected Employee is passed to the control.

To allow this to work, I have an ASCX User Control view named PersonInfo that derives from ViewUserControl<Employee>. The content of this view is incredibly simple in my example (UI design is not a focus of this post!);

<%@ Control Language="C#" AutoEventWireup="true"

CodeBehind="PersonInfo.ascx.cs"

Inherits="MvcAjax.Views.AjaxSample.PersonInfo" %>

Name: <%= ViewData.Name %><br />

Job Title: <%= ViewData.JobTitle %>

Browsing to /AjaxSample/ViewPeople will now render a list of all Employees, plus the details of a specific employee (the first one in the list) below the main list.

Adding AJAX

So my next task is to add AJAX that will allow the “Individual” DIV element content that contains the User Control to be replaced with the result of a call to a Controller Action of my choice. I love the lambda expression approach used by much of the MVC framework, so my ideal solution is to replace the “emp.Name” in the list of employees with code similar to that below that outputs a hyperlink to perform my update;

<%= Ajax.UpdateRegionLink<AjaxSampleController>(d => d.UpdatePerson(emp.Id),

"Individual", emp.Name) %>

Here I am specifying the Controller I want to use, the Action I wish to call (and its parameters), the name of the DIV element I wish to update the content of, and the link text (the Employee’s name).

Implementing this boils down to an extension method, which adds functionality to the AjaxHelper class. I came up with the following;

public static string UpdateRegionLink<T>(this AjaxHelper helper,

Expression<Action<T>> action,

string elementId,

string linkText) where T : Controller

{

string linkFormat =

"<a href=\"javascript:updateRegion('{0}', '{1}')\">{2}</a>";

string link = helper.BuildUrlFromExpression<T>(action);

return string.Format(linkFormat, elementId, link, linkText);

}

I then directly copied the BuildUrlFromExpression method from the MVC Toolkit implementation of the HtmlHelper class; in a real framework I assume this functionality would be shared, but this is a hack, not a real deliverable J

Basically all this function does is output HTML that looks like this;

<a href="javascript:updateRegion(

'Individual',

'/AjaxSample/UpdatePerson/3')">{Name}</a>

I love the automatic generation of the URL!

The code that is found at this URL is a very simple Action;

[ControllerAction]

public void UpdatePerson(int id)

{

DbDataContext db = new DbDataContext ();

Employee emp = (from e in db.Employees

where e.Id == id

select e).SingleOrDefault<Employee>();

RenderView("PersonInfo", emp);

}

It simply loads the Employee that matches the specified Identifier, and renders the “PersonInfo” User Control only – and this is the power of splitting up the UI into these parts.

Doh!

So where do I put the javascript definition of the function “updateRegion” that is called by the link generated by my extension method? I need to register it as a client script block... so my first attempt was to pass Page.ClientScript into my extension method, and register the prerequisite javascript there. If that worked, I was going to think about how to get hold of it through the ViewContext... if it is possible.

But it didn’t work. I’ve not gotten to the bottom of why yet, so I may well dedicate more time investigating in the future, but basically it doesn’t look like any client scripts are emitted when using the MVC framework. I guess this is something different about the page lifecycle execution, or perhaps an override in ViewPage.

Either way, my interim solution is to put the script in a “.js” file under the “Content” folder, and import it in the master page;

src="/Content/MvcAjaxExtensions.js">

</script>

The Script

The script is quick and dirty, designed to get the job done and that’s about all, as quickly and simply as I could think of! As with all the code in this example, it is nowhere near production strength (</excuse-making>).

var regionId;

var req;

function updateRegionReturn()

{

if(req.readyState == 4)

document.getElementById(regionId).innerHTML = req.responseText;

}

function updateRegion(elementId, url)

{

regionId = elementId;

req = new XMLHttpRequest();

req.onreadystatechange = updateRegionReturn;

req.open('GET', url);

req.send();

}

It simply uses the XMLHttpRequest object to make a request to the supplied URL – which of course was built by my extension method and passed into updateRegion() by the link we generate on the page.

It Works!

So it is a little hack, but the important thing is that the Proof of Concept works – try clicking a link on the People page, and hey presto, a web request is made, the Action is invoked, the User Control is rendered, and the mark-up is updated. I think this shows that AJAX support could feel really natural in the MVC framework – and there’s no reason why many of the standard AJAX functionality couldn’t be rolled in.

This is a very simple example, but I hope it has illustrated how the framework could evolve itself, or be built on to suit your own project.

ASP.NET MVC Framework Links & Info

simonince — Fri, 30 Nov 2007 02:03:00 GMT

This week is turning out to be a bit busy, so blogging is stumbling, and likely will next week too. Still, I managed to get time to read some other’s posts that are worth having a look at, in particular regarding the up-and-coming ASP.NET MVC Framework;

Scott has posted some info on the product roadmap and release schedules - a CTP of the MVC Framework (and more) is apparently due out next week.

If you haven’t found his blog yet, Fredrik has some good little posts on features of the MVC Framework.

Nikhil has a post about using AJAX with the MVC Framework.

Check them out!

The ASP.NET MVC framework, using the WCSF as a yardstick!

simonince — Thu, 22 Nov 2007 18:37:00 GMT

Well, right up until this morning I was planning on blogging about the similarities and differences between the patterns used by the Web Client Software Factory (WCSF) and the up and coming ASP.NET MVC Framework... and then I saw Glenn’s post linking to this great article on patterns used to structure User Interface code. Gutted. Someone has already done it, and what’s worse, they’ve done it much better and more thoroughly than what I had in mind!

Still, I think I can squeeze some mileage out of my thoughts over the past few days... J

Much of this post is my current evolving thinking on the two frameworks, and therefore if you disagree do feel free to chip in and air your views. I’m only specifically comparing against the WCSF because I feel they share many characteristics and address similar problem spaces, and so I think it leads to a good illustration of what the MVC framework might give us, and what you need to be aware of.

My thoughts are also based entirely on what information is in the public domain – I have not had any internal conversations about this, so not only does it “not necessarily represent the views of my employer”, but chances are it will be just plain wrong as CTPs start to appear... so join the debate!

In case you are not sure which patterns I’m referring to, have a quick read of the links under patterns used in the Web Client Software Factory. Specifically we’re interested in View-Presenter and Application Controller. For the MVC framework, there is an hour long video of Scott doing a demo, two posts by Scott here and here, and a good set of notes here.

So how do these WCSF patterns directly compare to those proposed in the ASP.NET Model-View-Controller framework? In the Web Client factory we have a Model (implied, although not named in View-Presenter), a View, a Presenter, and a Controller, and in the MVC framework we have a Model, View, and Controller. So surely the mapping is pretty obvious? Well, it isn’t the simple one-to-one you might think. Here’s what I’ve come up with so far;

Responsibility	WCSF MVP	ASP.NET MVC
Page flow	Controller (single)	Controller (many)
Business logic	Model	Model
Interaction with Business logic	Presenter*	Controller (many)
Presentation logic	Presenter	View (code behind)*
Presentation UI	View	View (mark-up)*

* Two points to note; a) you don’t necessarily have to split a View by code behind & mark-up in the MVC framework, but it seems a logical way to indicate the two roles a page can fulfil; b) many people use the Controller as a facade to the business logic in the WCSF, but the key above is that the instruction to interact with the logic is generally initiated by the Presenter calling a method on the Controller.

So what are these key differences? I’ll try to boil it down to some concrete points.

Controllers

The WCSF tends to have an Application Controller per module, but the MVC framework has many (likely to be one per group of views). So in the WCSF we might have a SalesController that handles all page flow (and potentially business logic interaction) for the Sales module. However, in the MVC framework we might have a PricingController, an InvoiceController, and a CustomerController. Page flow is not necessarily owned by any single Controller.

There may therefore be an opportunity in MVC framework applications to use something similar to an Application Controller to centralise some of the page flow; perhaps by directing all relevant requests to a single Controller Action on an Application Controller to route appropriately. More thought required I reckon!

Entry Points

The primary entry point to the WCSF framework is the View followed by the Presenter. So when the user browses to “~/DisplayProducts.aspx”, the DisplayProducts page is constructed, and the DisplayProductsPresenter is attached to it. This Presenter then drives interaction with the Controller as required to fetch Model data, decide on Page Flow, and so on.

In the MVC framework, the primary entry point is a Controller, as Controllers are URL addressable. So when the user browses to “~/Products/Display”, the ProductsController would be created, and it’s “Display” action would be invoked. This then interacts with the Model and decides which View to use to render the output.

This also drives the relationship between Views and Controllers; rather than there being one Controller for a set of Views (as I approximated above) it is really that an area of functionality has a single Controller – and that Controller may have a set of supporting Views. Therefore the Controller becomes the primary unit driving application functionality, contrary to the WCSF, in which Views are the primary unit that drives functionality.

Of course, the more obvious point to note on Entry Points is the REST-friendly URLs that the MVC framework uses by default. I don’t personally think this adds any significant benefits, but it certainly looks clean and sits with the framework well.

Views

The MVC framework has no separation of View and Presenter. The WCSF splits presentation logic into a Presenter class, and the technology-specific implementation of this into an ASPX page that implements the View definition. Conversely, in the MVC framework all logic to co-ordinate the physical rendering of a result set is contained in an ASPX page.

Perhaps an interesting point here is that the MVC framework’s Controller actually does much of the work that the WCSF’s Presenter does (in initiating interaction with the Model), and therefore MVC framework Views are expected to be significantly simpler than the View-Presenter pairing in the WCSF – pretty much just rendering mark-up and data binding expressions. This simple presentation code is roughly equivalent to what is contained in the WCSF’s View implementation (without the Presenter). So is there any point in separating further “presentation logic” in the MVC framework?

There are two reasons why a Presenter is useful in my opinion;

a) When there is real logic required to decide how to render a View.

b) When this real logic would benefit from Unit Testing.

But the approach encouraged by the MVC framework is to avoid logic in a view, and to stick to pretty straightforward data-binding etc. Instead of one complex View, you may choose to have many simpler Views. For example, if you have a list of products that can be clicked to display details of each, in the WCSF you may implement this as a single View with collapsible sections... hence there is logic to handle clicks, showing and hiding sections, retrieving data, and so on. However, in the MVC framework this would possibly be better implemented as two Views – a list View, and a details View. When the list is clicked, the request goes through to the Controller which renders the result using the details View. This is in fact likely to be necessary to avoid the View from interacting with the Model. (How does it get the individual product’s details if a View can’t interact directly with the Model? It can’t! It needs the Controller to do that first.)

ASP.NET

Something not so obvious is the way in which each framework sits in the ASP.NET runtime. Scott points out the following in this post about the MVC framework;

The MVC framework supports using the existing ASP.NET .ASPX, .ASCX, and .Master markup files as "view templates" (meaning you can easily use existing ASP.NET features like nested master pages, <%= %> snippets, declarative server controls, templates, data-binding, localization, etc). It does not, however, use the existing post-back model for interactions back to the server. Instead, you'll route all end-user interactions to a Controller class instead - which helps ensure clean separation of concerns and testability (it also means no viewstate or page lifecycle with MVC based views).

In other words, the choice to force all requests through the Controller outlaws the post-back model. In contrast, one of the goals of the WCSF was to support standard ASP.NET functionality wherever possible, to maximise the speed at which developers could get going with it, and allow it to sit well with existing frameworks. This is of course because the WCSF is an accelerator built on the framework, and the MVC framework is just that... an underlying framework.

The choice not to support post-backs in the MVC framework makes absolute sense to produce a more purist application architecture, but it does mean that developers must shift how they think about writing aspx pages.

I’ve mentioned this in a discussion about the patterns because I think it helps define component responsibilities – i.e. a View is much more lightweight in the MVC framework than a classic ASPX page might be. It moves the focus away from building WinForms-like pages to building simple rendering-only templates. I personally believe that if you make this leap, you’re more likely to avoid building monstrous pages that rely heavily on View State, and are difficult to test and maintain...

I also wonder what kind of benefits we may see by not using View State, not going through a page initialisation and load for every post-back button click...

The End... or rather, The Beginning

To conclude, then, my view is that these two frameworks share some common objectives and techniques, and therefore that each can potentially contribute significantly to the other. In the comments on his posts Scott implies a CTP is just around the corner, so let’s look forward to playing with it for real.