Melvyn Harbour : ASP.NET

Combining ASP.NET MVC and ASP.NET Charting Controls

MelvynHarbour — Tue, 25 Nov 2008 16:22:00 GMT

As ScottGu recently posted on his blog, Microsoft have recently released a set of charting components. Several people followed up with comments on his post asking whether it was possible to use them with ASP.NET MVC. The good news is that it certainly is, if you are using ASP.NET as the View engine (the default). And there's actually relatively little that you have to do. This post outlines the steps you'll need to take to get it up and running.

You'll need to first add the references to the appropriate assemblies (System.Web.DataVisualization and System.Web.DataVisualization.Design if you want design support). You also need to add a couple of lines to your Web.Config file. In the <controls> section, you will need to add:

   1: <add tagPrefix="asp" namespace="System.Web.UI.DataVisualization.Charting" assembly="System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>   2:  

You'll also need to add a new line to the httpHandlers section:

   1: <add path="ChartImg.axd" verb="GET,HEAD" type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler, System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="false"/>   2:  

It's then pretty much simplicity itself to add a chart to a view page - you just drop it on as a server control exactly as in the examples in the sample project linked for Scott's post. You'll obviously need to call the code to insert the DataPoint objects into an appropriate Series, and this will probably lead to a few lines of code in the code behind file, but given that the data-transfer objects between the controller and the view are generally reasonably well structured, this code should be both readable, and fairly short, so I don't think that it's really a problem.

I think the best approach if you are interested in doing this is to simply have a go and see how it gets on. I think it's a nice simple solution myself and certainly doesn't represent a great deal of overhead to get the result out.

MVC ModelBinder and Localization

MelvynHarbour — Fri, 21 Nov 2008 11:13:00 GMT

One of the great things about the way in which the Microsoft ASP.NET MVC Framework is being developed is the fact that the team are publishing the source code as they go along. This makes it very simple to dig into the framework when something slightly surprising is happening and figure out exactly how it is supposed to work. A good example of this cropped up for us yesterday when looking at a form posting scenario using DateTimes. We were dealing with an Action Method that looked something like this:

   1: public ActionResult DoSomething(DateTime theDate)   2: {   3:     return View();   4: }

And using the automatic model binding infrastructure to set the method parameter from a form. Naturally, being based in England, we were not totally shocked when we ran into localization issues almost immediately with this. It appeared at first glance that the date was being parsed assuming en-US format (mm/dd/yyyy), whereas for the application we were writing, which will be used internally be people who will expect to use en-GB (dd/mm/yyyy), we wanted it to parse in a different format. This prompted some investigation to discover what the framework was using to make its decision about which culture to use. The result turned out to be somewhat more clever than we had first thought, and nicely illustrates the way in which MVC Framework applications should be structured.

The initially surprising piece of information that it transpires that it actually matters whether you have set the HTTP method to be a GET or a POST. To understand why this is the case, here is a snippet from within the MVC source code. I have removed several lines from the code to make it easier to see what is going on. If you want to see the original, it is within GetValue(string name) of System.Web.Mvc.DefaultValueProvider.

   1: CultureInfo culture = CultureInfo.InvariantCulture;   2:     3: if (request.QueryString != null)   4: {   5:     rawValue = request.QueryString.GetValues(name);   6: }   7: if (rawValue == null && request.Form != null)   8: {   9:     culture = CultureInfo.CurrentCulture;  10:     rawValue = request.Form.GetValues(name);  11: }

In other words, when looking for the value to parse, the framework looks in a specific order namely:

RouteData (not shown above)
URI query string
Request form

Only the last of these will be culture aware however. There is a very good reason for this, from a localization perspective. Imagine that I have written a web application showing airline flight information that I publish online. I look up flights on a certain date by clicking on a link for that day (perhaps something like http://www.melsflighttimes.com/Flights/2008-11-21), and then want to email that link to my colleague in the US. The only way that we could guarantee that we will both be looking at the same page of data is if the InvariantCulture is used. By contrast, if I'm using a form to book my flight, everything is happening in a tight cycle. The data can respect the CurrentCulture when it is written to the form, and so needs to respect it when coming back from the form.

But this brings us back to a consideration of the HTTP method that has been used. Remember that if we set the form to be HTTP GET, when the form is submitted the values of the fields in the form will be turned into a query string. So they will be parsed with the InvariantCulture rather than the CurrentCulture, as they would have been if it were an HTTP POST. We can therefore toggle the behaviour of the form (from a localization standpoint) by changing the HTTP method.

Now to me this seemed slightly surprising at first, but I can certainly see that from the framework authors' perspective, it's the correct way of doing things. It still does leave one loose end, from a technical perspective. Suppose now that out airline flight information application allows the user to type in a date for which they wish to view flight information rather than clicking on a (computer generated) hyperlink. This is not an unreasonable behaviour, and is probably far more realistic of the way that the application would in fact be written. I still want the form to submit via HTTP GET rather than POST, as I want a URL to be generated that my user could email to his colleague. Effectively therefore, I have mandated that the user needs to enter the date using the InvariantCulture, which is hardly very localization friendly! If the application is only going to be used by people in (for example) en-GB (as might be the case for a company internal application), it is very possible that the date format will be known, and specified.

Help is at hand though! Luckily, the way that the MVC Framework has been written makes it very easy for us to drop in other components to ensure that specific parts of the application such as this run the way that we expect them to. In this instance, what we want to do is register a new ModelBinder that will handle this DateTime to parse it using a specified culture. Writing a new ModelBinder is actually staggeringly simple. All we need to do is implement IModelBinder, and then register the new ModelBinder in Global.asax.cs. A very simple example of a custom ModelBinder to force the binding of DateTimes to always use en-GB is given below.

   1: public class MyBinder : IModelBinder   2: {   3:     4:     #region IModelBinder Members   5:     6:     public ModelBinderResult BindModel(ModelBindingContext bindingContext)   7:     {   8:         string theDate = bindingContext.HttpContext.Request.QueryString["theDate"];   9:         DateTime dt = new DateTime();  10:         bool success = DateTime.TryParse(theDate, CultureInfo.GetCultureInfo("en-GB"), DateTimeStyles.None, out dt);  11:         if (success)  12:         {  13:             return new ModelBinderResult(dt);  14:         }  15:         else  16:         {  17:             // Return an appropriate default  18:         }  19:     }  20:    21:     #endregion  22: }

We then just need to tell MVC to use the ModelBinder. All this takes is a line in Global.asax saying:

   1: ModelBinders.Binders.Add(typeof(DateTime), new MyModelBinder());

Of course the custom ModelBinder could be modified to do anything else that you want to, or indeed descend from DefaultModelBinder, and use other properties of the binding to help it determine whether it should use the new behaviour, or leave it up to the original DefaultModelBinder. The above example isn't particularly realistic in that we have mandated that the value of a DateTime will be coming in on a query string parameter of 'theDate'. It would normally be the case that we would use other properties of the ModelBindingContext to be more accurate about the situations we need to override. The ModelBinder could also be specified explicitly using an attribute on the method parameter.

On a side note, I thought it would be worth linking to an article featuring Red Gate's biggest fan!

How to use the ASP.NET MVC ModelBinder

MelvynHarbour — Fri, 29 Aug 2008 10:30:00 GMT

One of the new features in the latest build of ASP.NET MVC is the ModelBinder, which is provided to allow Action methods to take complex types as their parameters. Previously, action methods were only able to take simple types such as strings and integers as their parameters. The new ModelBinder provides the facility to build complex types from component parts that (for example) may be part the result of submitting a form with several fields. To see an example of this in action, we will first need a fairly simple class to work with. The following class definition will typically be placed in the Models directory. I have left the using statements at the start of the file as an 'exercise for the reader'!

   1: public class MBTest   2: {   3:     public string Name { get; set; }   4:     5:     public MBTest()   6:     {   7:     }   8: }

All fairly standard stuff. Now let's create a form on our index page that we can use to have a play with one of these objects:

   1: <% using (Html.Form("Home", "About")) { %>   2:     <input type="text" name="Name" />   3:     <button type="submit">Submit</button>   4: <% } %>

Again, just the relevant form supplied here, and kept as simple as possible for clarity. Nothing in the routing needs to change: that will all happen just fine. Now, the aim is to write an Action Method that looks like the following:

   1: public ActionResult About(MBTest testItem)   2: {   3:     ViewData["Title"] = "About Page";   4:     5:     return View();   6: }

Admittedly, this method doesn't actually do anything with the testItem object that it creates, but it could quite easily if it wanted to. What we want is that the Name property of testItem is populated with the contents of the text input field in our form. Previously, we would have done this by inserting code into the About method above to parse the results coming back. So here's the new bit. We create a helper class that will carry the knowledge of how to perform the translation from the form to the complex type. This class must implement the new interface IModelBinder.

   1: public class MBTestBinder : IModelBinder   2: {   3:     #region IModelBinder Members   4:     5:     public object GetValue(ControllerContext controllerContext, string modelName, Type modelType, ModelStateDictionary modelState)   6:     {   7:         MBTest instance = new MBTest();   8:         instance.Name = controllerContext.HttpContext.Request["Name"];   9:         return instance;  10:     }  11:    12:     #endregion  13: }

Obviously this is a very simple example, and I haven't used most of the information passed to the GetValue method, but the intention of this post is primarily to be a starting point, just to get you 'up and running'. So the MBTestBinder class functions as a bridge, in a similar way to an ADO.NET DataAdapter. There's one final step to getting this all hooked up, and that's to tell the code to use MBTestBinder. This is done by applying the new ModelBinderAttribute to things. There are actually two different places you can use this attribute, with the same effect. The first is by decorating the model class:

   1: [ModelBinder(typeof(MBTestBinder))]   2: public class MBTest

The second is decorating the parameter of your Action Method directly:

   1: public ActionResult About([ModelBinder(typeof(MBTestBinder))]MBTest testItem)

My guess is that they've left the choice in because the decision about exactly where bridge classes such as MBTestBinder actually lives is not a straightforward one. Others will no doubt contribute much more involved examples and discuss whether this solution to the problem is even the correct one, but hopefully this post explains enough to enable people to get started with experimenting with it and getting a feel for it.

ASP.NET MVC Codeplex Preview 5

MelvynHarbour — Fri, 29 Aug 2008 08:53:00 GMT

ASP.NET MVC Codeplex preview 5 went live last night. Available here. I haven't had a dig into it yet to have (just downloading now), but according to the release notes, some of the highlights include:

More support for partial view rendering
Moving AJAX support into its own namespace (System.Web.Mvc.Ajax) to make it easier to swap it out and replace it with your own choice, such as jQuery.
Complex types as parameters of action methods (some discussion of this already in my post http://weblogs.asp.net/melvynharbour/archive/2008/07/30/clean-separation-of-concerns-in-mvc.aspx and the associated forum thread).
Various other tweaks and improvements particularly to helper methods.

The source code apparently follows shortly!

Clean Separation of Concerns in MVC

MelvynHarbour — Wed, 30 Jul 2008 10:39:00 GMT

One of the main areas that is cited as a benefit of using the new ASP.NET MVC Framework is that you can obtain a 'clean separation of concerns'. But the question is, what does this really mean, how achievable is it in reality, and should we really be interested in doing it?

What does it mean?

Well, from Wikipedia (http://en.wikipedia.org/wiki/Separation_of_concerns) - 'the process of breaking a computer program into distinct features that overlap in functionality as little as possible'. The article goes on to say that the MVC design pattern aims to separate content from presentation and data-processing from content. This is all well and good, but where do the lines of separation fall. One is reasonably clear - between the data-processing (Model) and the rest of the application. Almost every attempt at writing an MVC Framework web application illustrates this successfully.

The slightly harder area to tie down the separation for is when you look at Views and Controllers. Where should the separation occur? What is the division of responsibility? Should the two portions be completely independent, or can they have knowledge of each other? At a certain level, it is reasonably easy to provide some definitions: the view takes responsibility for presentation, and the controller takes responsibility for actions. But there is clearly a grey area in the middle. Clearly most actions can be completed without much dependency on the view that is their 'end point', but the reverse is not necessarily true. In a simple 'display' view there is no problem, but by the time we move to 'editors', we are starting to get into the realms of some trickiness of definition. In fact the way the view is set up may have critical importance to the nature of the controller. This is probably best illustrated with an example. Let us say that I have written a appointment diary application. One of the editors in this is used to change the date of an appointment. I could choose to display this date in one text-box (DD/MM/YYYY format), or I could decide that it will be easier to use if I split it and put the day, month and year components of the date in different text-boxes. Either way, I have introduced a link between the way the data was displayed and my controller. If I change one way of displaying the date into another, I may need to change the controller, unless the view takes care of returning the date to the format from which it 'came'.

But here lies another problem - 'format from which it came'. It's perfectly legitimate in MVC that the View may have fetched the data it is displaying from the Model directly and that the Controller had no knowledge of the original form of the data at all. Either way, we are getting towards the situation where the Controller needs knowledge of at least one of the Model and the View in order to function. The problem really comes from the nature of HTTP. The View is split between what it was on the server, and what is able to be transmitted 'over the wire'.

So is full separation achievable?

Well, we could remove the requirement that the Controller knows things about the View. It would require something of a rethink to the way the MVC Framework is currently designed though. It would require that Views 'submit back to themselves', that the View can then sort out the data before triggering an appropriate Controller action. But there is a problem. We've essentially introduced a dependency that the View now needs to know about the Controller. So we're back to square one! I therefore don't think that the View and Controller having no knowledge of the structure of each other is practical. They are implicitly linked.

Where does that leave us?

Well, not all at sea, thankfully! And luckily, I think in considering what we really mean, we come to what really turns out to be a very good way of architecting an MVC web application. I believe that the separation is not a totally strict one of encapsulating all knowledge about the different portions of the code, but rather a clean separation between behaviours and views. Interestingly, this is one of the key points of object oriented design that is often overlooked - designing an application by the behaviours that it must be capable of. The REST-like routing system built into the MVC Framework as it stands takes you even further down this route of considering the application to be much like an object oriented design. Essentially therefore, Controllers can (in some sense) be likened to classes (and indeed this is the language construct they use!), and Action methods are the behaviours of which a Controller is capable. The big advantage of these Action methods being thought of as behaviours is that writing Unit Tests for them becomes a very natural process.

The conclusion of all of this is that there is going to have to be linking between your Controllers and Views. They can't be written to operate independently. The key point is to see the separation between behaviours and templates. Don't code things that are going to cause a change to the model into your View, and don't code things that are purely a matter of presentation into your Controllers, but expect a certain amount of grey area where the communication between them is concerned.

MVC AJAX Support

MelvynHarbour — Tue, 22 Jul 2008 09:55:00 GMT

In the latest preview of the Microsoft ASP.NET MVC Framework, one of the newly included features is AJAX helper methods. It's going to be interesting to see where they go with these. At the moment, they've added just a couple of tasters. This blog post discusses how to set them up and make use of them if you want to try them out. Currently, there are two helper methods that have been created, Ajax.ActionLink and Ajax.Form. I will discuss both below. They both generate HTML, much in the manner of pre-existing helpers such as Html.Form.

The first thing to look at is how to set a page up to be able to make use of these helper methods. Since they are going to call parts of the JavaScript libraries that are part of the Microsoft AJAX Framework, you need to include them in the head section of your page. There are two files that you need to include. Microsoft are currently shipping them in both debug and release configurations. It doesn't matter whether you have debug or release, but you will need to have both files included, and included in the correct order. This will look something like the following:

   1: <head runat="server">   2:     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />   3:     <title>AJAX Example</title>   4:     <link href="../../Content/Site.css" rel="stylesheet" type="text/css" />   5:     <script type="text/javascript" src="../../Content/MicrosoftAjax.js"></script>   6:     <script type="text/javascript" src="../../Content/MicrosoftMvcAjax.debug.js"></script>   7: </head>

Once these have been included, you will be free to use the AJAX tools that have been developed. It is worth a quick aside to briefly discuss the payload size of these Framework helpers. Currently, MicrosoftAjax.js represents about 89KB and MicrosoftMvcAjax.debug.js is about 6KB. These numbers obviously aren't too bad. They're bigger than the equivalent jQuery files, and it will be interesting to see how it matches up as time goes on.

Having set up the Framework requirements, we can proceed to use the tools supplied. The essence of the helpers that have been created so far is that they allow you to easily make an asynchronous call to a Action Method and to use the response. This essentially makes it possible to create the equivalent of the UpdatePanel from WebForms. This is probably best now illustrated with a simple example, building on top of the standard MVC site that is shipped with the Framework. In the code for the Index view (Index.aspx), we can include something like the following:

   1: <div id="testContainer">   2:     <%= Ajax.ActionLink("About", "About", new AjaxOptions { UpdateTargetId = "testContainer" })%>   3: </div>

The next stage is to alter the About view (About.aspx) to remove most of the strapping from it. It is not going to need to have a MasterPage for example, or in fact to have anything but some example text.

So, what is the effect of all this? Well, run it up in a browser and we'll see what happens. As you might expect, running the default page for the site brings up the Home/Index page as normal. Some way down the page, there is a link with the text 'About'. So we click on it. What should happen, all being well, is that the contents of the About view becomes inserted into the page in place of the About link.

Obviously, there is fairly limited potential in links for passing information back to the controller, so the natural extension is to want to have an 'AJAXified' form. And lo and behold, one exists. Ajax.Form works in a very similar manner to Html.Form (with the exception of needing AjaxOptions just like ActionLink does). And indeed it 'just works' much like you would expect.

One final aspect of this Framework is worth discussing in this post I believe, and that is controlling what view is selected. Obviously if we have received a request as an AJAX request into the controller it is highly likely that we will want to show a different view to if we had received it as a normal HTTP request. In this case, there is a helper method that is your friend:

   1: if (Request.IsMvcAjaxRequest())   2: {   3: }

This does exactly what it says on the tin and will tell you from where a request originated. The most obvious use of this is, as mentioned above, in switch which view to use. The fact that a view can be an ascx file just as easily as an aspx file gives us therefore a fairly neat way of providing a page with something that will feel a lot like an UpdatePanel in the centre. Instead of the UpdatePanel, we can make the part of the page that will update an ascx file and then include it as a UserControl in our normal view page. We therefore serve the aspx page the first time (when the request is a normal HTTP request) and can then serve just the ascx file for subsequent MVC AJAX requests.

I do feel at the moment that this framework offers only fairly coarse grained control compared with what is currently available through something like jQuery. The word on the street (or at least ScottGu's blog) is that they're making this a pluggable part of the process just like every other part of MVC. Certainly for ActionLinks at the moment, I think jQuery represents a better solution (lighter, more flexible and just as powerful). For Ajax.Form, I'm not sure one way or the other yet, but it does look like a relatively neat solution. You can certainly achieve the same functionality using jQuery and cause a form to POST, but it does require a certain amount of duplication of code between the jQuery code and the HTML code to set up the form.

MVC Preview 4

MelvynHarbour — Mon, 14 Jul 2008 11:01:00 GMT

It's been announced on ScottGu's blog that MVC Preview 4 is due out later this week. Obviously we'll need to wait and see what it feels like when we get to have a play for real with it, but first impressions from reading down the article is that they seem to have nearly nailed down the core API to create a version that's close to what will go live, and are now busy working on all the bits and pieces that will be necessary for actually using it in a commercial sense. So we're now getting good authorisation, error handling and the like. I'll be getting it as soon as it's released and giving it a good going over to see how the new features play.

MVC training day 2

MelvynHarbour — Wed, 09 Jul 2008 12:37:00 GMT

Back for more! We started the day with a quick look at Dynamic Data (no more than an overview for those that hadn't seen it before), then moved on to look at unit testing the MVC framework, before finishing off with a look at jQuery and how it works with MVC.

Unit Testing

We looked at unit testing using NUnit and Moq. It was the first time I'd used Moq and it was interesting seeing just how well the approach fits with MVC. Essentially the idea was to be able to simulate the whole HTTP Context outside of a web server, using mock objects. Steven had written a helper class that mocked up the various parts of things like the request that would be needed to let a web application run successfully. This worked very neatly and allows you to push on in a rather succinct way with your testing and write very nicely structured tests that achieve good coverage of your controllers. Obviously, this does not cover unit testing of the views, but that's a slightly different problem.

jQuery

I've used jQuery before on 'Classic' ASP.NET projects, but it's pretty good seeing how easily it fits in with the MVC framework. The tighter control of the HTML output you get with MVC certainly lends itself much more readily to jQuery manipulation. No more worrying about exactly what the ClientID is going to be!

Steven commented that the word on the street was the Microsoft are saying that they're going to be introducing some sort of AJAX compatibility layer before MVC goes RTM, but it's not yet clear what that's going to be.

MVC training day 1

MelvynHarbour — Tue, 08 Jul 2008 13:47:00 GMT

We've had the first of our two half days with Steven Sanderson this morning. It was split in half, with the first half covering the new C# 3.0 language features and the second tackling MVC.

LINQ

We went through some fairly basic examples of LINQ to Objects just to bring everyone up to speed, covering the major language features involved (extension methods, lambdas, generic type inference, automatic properties, anonymous types and the like).

MVC

Moving on to the real meat of the session now! Steven first covered some of the reasons behind MVC. This includes things like the fact that we have fairly limited control over the rendered HTML with WebForms, a false separation of concerns and that it is fundamentally hard to test. He stressed that WebForms fundamentally does quite a good job of what it was designed to do, namely help people coming from a WinForms background in migrating to writing Web Apps. However it doesn't really 'play nicely' with the way the Internet really works.

We then went through a worked example, building up a sample application. Coming from a Perl/CGI background originally (before I got into ASP.NET) I felt that a lot of what I was seeing was very good and that it stands a chance of removing some of the dirty hacks that start to creep in when you want to do anything more complicated than 'My First WebForm'. It's important to recognise that it isn't for everyone however: you need to understand far more about the way the Internet and HTTP really work in order to get the most out of MVC. That said, if you do understand, you're going to be able to push the tech a lot harder before it starts to fight back!

I've watch a few presentations on MVC before, but this was the first time I've actually 'got my hands dirty' with it. I am really excited about the direction it's going. There's no doubt that you are forced to think about your web applications in a very different way when using it compared with WebForms, but I don't think that's necessarily a bad thing. It's certainly a technology that we're going to be exploring here in Red Gate's web division (although obviously you're unlikely to see anything written 'for real' in it until it goes to version 1 - probably some time in Q4 2008).

Tomorrow we've got sessions looking at unit testing and how it fits into MVC, followed by using jQuery and AJAX with it.

MVC Training

MelvynHarbour — Mon, 07 Jul 2008 10:50:00 GMT

Starting tomorrow we've got a couple of training sessions on the new ASP.NET MVC framework lined up here at Red Gate with Steven Sanderson. Steven used to work here, but is currently busy writing one of the books that's going to be an authority on the subject. Check it out here!

In the web team here we're all looking forward to it and hopefully I'll write up some of the more interesting aspects here! If anyone has any specific questions that you'd like me to put to him, leave a comment below and I'll see what I can do.