For this project the following (extensive) list of libraries is used (all these libraries are included in the download):

• MS ASP.NET Mvc 1.0
• Microsoft .NET RIA Services July 2009 Preview
• NHibernate 2.1.0CR1
• NHibernate Linq (latest trunk version)
• FluentNhibernate (latest trunk version, patched to work with NHibernate 2.1.0CR1)
• MS Unity 1.2
• ASP.NET Dynamic Data MVC Preview (since this project is pretty old, I had to modify it quite a bit, the source is included in the download)
• I used Rob Conery’s t4 templates as the base to generate entities from the database.

Besides using these libraries, I copied some code snippits from the Kigg project, which has quite a nice codebase!

In the first part of this serie, I’ll show you how you can use these libraries along with my own code to scaffold the entire Northwind database in an mvc project. It’ll be totally hassle-free, I promise! It will generate classes from the database-schema and I will also show you how to override the default generated domainservices and repositories (yes, those are generated at runtime if you don’t specify your own!).

In the upcoming parts, I will add client-side validation and some ajax-love to the scaffold pages. In one of those parts I’ll also explain how my code works, and what it does. I’m also thinking about showing how to replace some parts of the library, since it’s very pluggable. I could for example replace the persistencelayer with Linq-to-Sql or replace the Depency part with StructureMap.

Although this sample shows you how to use an existing database, it would ofcourse be best if you could use the Model-first approach! Luckely nHibernate makes this very simple as well. If you create the entity files in your project and have them inherited from BaseEntity, all you have to do is add this line to your Application_Start:

new SchemaUpdate(IoC.Resolve<Configuration>).Execute(true, true);

Your database schema will be automatically updated if you change anything to your Model.

You can watch the screencast here and download the sample + dll’s here

For the next screencast, I’ll by a mic so I don’t have to subtitle it

The javascript-only package includes 3 javascript files that allow you to use the default Microsoft AjaxHelper. You can just copy those files to your Content folder and include them in your head section, instead of the MicrosoftAjax.js and MicrosoftMvcAjax.js. All ajax extensions work the same as their Microsoft equivalence,  using jQuery instead of MicrosoftAjax. As a little bonus, you’ll get back and forward button support for your ajax-links.

That’s it, go ahead and use the AjaxHelper functions like you’re used to. Though a few things have changed for the AjaxHelpers in preview 5, you could still use the introduction ASP.NET MVC Preview 4 – Using Ajax and Ajax.Form by Scott Hanselman if you haven’t already checked out the AjaxHelper. Main thing that has changed is that you cannot use inline javascript in the AjaxOptions in preview 5, you should now specify a method name. You could also download the entire jQueryMvc project, it holds a sample website showing some of the ajax magic.

Talking about the entire project, it’s more than just the .js files! The intention of the project is to get you up and running very quickly when you want to create an mvc based ajax application. We use Unity as our default IoC container.

I think it’s quite hard to explain exactly what the project does for you, it’s best really to just look at the sample website, but I will give a brief overview. First, we have a DefaultViewViewEngine. If you mark your controller with a [DefaultView] attribute like so:

If you call in example /Home/Index, by default the Index view will be searched for. If it isn’t found, the DefaultViewViewEngine will look for a template with the name specified ("default" in the above example). It doesn’t matter what viewengine you use for your views, it will work for all of them. So what can this do? Look at the structure of the views in the sample site:

As you can see, most of the the views only have an ascx file prefixed with an underscore. Since the views are not found when the actions Home/About, Home/SayHello, Home/Index are called upon, the DefaultViewViewEngine will open Shared/Default.aspx.
This default page does not do much

As you can see, it just uses the masterpage. But with only little imagination, you can see that you can easily create different default-pages for each controller. The masterpage however, does hold some extra magic:

This special contentplaceholder, by default works like a normal placeholder. But, if it doesn’t get new content from it’s page, it will ask the ViewEngine(s) to open the view of the current action prefixed with an underscore. So, if you call Home/About, this will ask for Home/_About. 
Can you see the magic? For all similar pages, you just have to create the ascx files (or other partials if you use a different viewengine). Those partial views will be pushed into the main page.

But wait, there’s more! If you make an ajax-request to a controller that has the [AjaxController] attribute, it will return only the partial view! Now, isn’t that great ? That looks a lot like the updatepanel to me

Go to codeplex and download the project to see the ajax-magic I’m so excited about!
Source can be downloaded at Google code: http://code.google.com/p/jquerymvc/source/checkout
The sample website can be seen in action at: http://www.chrisvandesteeg.nl/demo/jquerymvc5/

Unfortunately the AjaxHelper itself is sealed, so atm we can’t (easily) change how the AjaxHelper generates its links. So, as an alternative, I created a javascript library that uses the same methodnames as the MicrosoftMvcAjax version.

Though at first I was upset that AjaxHelper wasn’t opened up, this javascript-only solution makes it very easy to use. All you have to do is

• place the latest jQuery version in your Content folder;
• place my javascript file in your Content folder;
• add references in your views (or masterpage ofcourse) to these 2 files instead of referencing the MicrosoftMvcAjax.js and MicrosoftAjax.js file.

If you haven’t played with the AjaxHelper yet, take a look at Scott Hanselman’s post on Using Ajax and Ajax.Form

This jQuery version also has a little extra: browser-history support for your ajax requests

Now, go download the js file and play!

So, quite some things have changed in preview 3, which made me decide to change a lot in the jQuery for Asp.net mvc (jqmvc) too. To start with most radical one: I ditched the ajax.master. This little ‘framework’ does not rely on a special masterpage in your website from now on. Since things have radically changed, I’ll start all over again on how to use this project.

In this post, I’ll explain how the project works globally. I won’t go into too much details about everything, but I will just explain the things you’ll directly touch in your application. In the next post, I’ll explain how to use the project in your website (until that time you could take a look at the included sample website). That post will explain the Ajax- and HtmlHelpers in this project and it will explain how to do an ajax request using jQuery.

Before my story starts, let’s start with the links and downloads for all those who want to read code rather than stories :

• Downloads 
• SVN source Repository
• The online demo
• Codeplex homepage

Application and routes

To have a quick go for your application, it’s recommended that you inherit your application from JqueryMvc.JqueryMvcApplication. You can ofcourse easily do this in your global.asax like so:

This application sets up the Unity dependency container and will set up the default routes. If you wish to setup a different (or no) dependency container, you should override InitializeContainer() and ConfigureContainer(). JQueryMvc itself is no longer dependent on a dependency container.

I found it hard to set up the default routes in preview 3 if your server does not support wildcard redirects (like visual studio’s webdevserver doesn’t). In that case you need to catch existing files (default.aspx needs to exist, but shouldn’t do anything), but you need to skip the Content folder. I came up with the following solution:

So if there’s a default.aspx in the root of your application, it set’s routeExistingFiles to true. If the url matches the RegEx ^Content\/.* the routing will be stopped using the new IgnoreRoute method. Also, your controllers will then be extended with .aspx to be sure the requests passes the asp.net cycle. If you have the option to catch all incoming requests, all you have to do is remove the default.aspx from the root of your website.

Controllers

As you’ve seen in Scott’s post, controllers should now return an ActionResult. The normal way would be to have your controller action return the result of the View() method. With jqmvc you should not call the View() method at the end of your action. Ofcourse, if you’re sure you want to return the normal view, you could still do so. In jqmvc there is a ExtController which you should inherit your controllers from. This baseclass contains a method called Action() which accepts the same attributes as View() but does some magic to decide what type of request the current request is, and will try to return the correct ActionResult for that type of request. This could be either an Ajax-request, a Json request or a normal page-request. Your typical controller with some actions would look like this:

Views

If jqmvc encountered the current request as a normal page request, it will create the default ViewResult, nothing special there.

If jqmvc decided Json should be returned, a JsonResult is created and no further actions will be taken. The rendered view will be the ViewData serialized to Json. The ViewEngine of the controller is also changed to a JsonViewEngine but this is only called upon in case of an Exception.

If jqmvc decided that the request is an Ajax request, it will create a normal ViewResult, but it will change the ViewLocator of the controller.
(Offtopic: I think it’s a design-error to have the viewlocator on the controller. It should be on the ViewResult object, that’s the only object that uses it. Perhaps this will be changed in the next preview…)
This AjaxViewLocator will first look for .ascx files instead of .aspx files. If it can’t find the .ascx it will load .aspx afterall.  You can also create a target-specific .ascx file: if you do an ajax-request through our javascript function jQuery.mvc.request() (or one of the htmlhelper functions), you have to specify a target for the loaded content. Let’s say we want to load /Home/Index into a <div id="dynamiccontent"></div>
The AjaxViewLocator will then look for :

1. /Views/Home/Index.dynamiccontent.ascx
2. /Views/Home/Index.acx
3. /Views/Home/dynamiccontent.ascx
4. /Views/Home/Index.aspx
5. /Views/Shared/Index.dynamiccontent.ascx
6. /Views/Shared/Index.ascx
7. /Views/Shared/dynamiccontent.ascx
8. /Views/Shared/Index.aspx

To have the page /Home/index available both as an ajax request as well as normal request, you could create an /Views/Home/Index.aspx which loads the index.ascx like so:

Things to know

• We have some HelperClasses to simplify the use of jqmvc

• The ViewData keys "Messages" and "Errors" are treated specially by jqmvc.

• Your page should always contain:

  • <%= Html.RegisterJqueryMvc(Page.ClientScript) %> To register the required javascript files

  • <div id="loading"></div>; or something else with id="loading". This will be made visible during ajax-requests

  • <div id="errors"></div> to display errors

  • <div id="messages"></div> to display messages (informational)

• We have a special contentplaceholder in JqueryMvc.UI.WebControls.ContentPlaceHolder. This will use the AjaxViewLocator to load some default content. Eg, if used like this in your masterpage, and the current request is /Home/Index:
  <jq:ContentPlaceHolder ID="maincontent" runat="server" />
  It will look for for content in:

  1. /Views/Home/Index.maincontent.ascx
  2. /Views/Home/Index.acx
  3. /Views/Home/maincontent.ascx
  4. /Views/Home/Index.aspx
  5. /Views/Shared/Index.maincontent.ascx
  6. /Views/Shared/Index.ascx
  7. /Views/Shared/maincontent.ascx
  8. /Views/Shared/Index.aspx

     This way, your index.aspx could just be an empty page that points to MasterPage with this default-content-loading contentplaceholer.

• Your ascx files should inherit from JqueryMvc.Mvc.ExtViewUserControl to have access to the AjaxHelper (bug in asp.net mvc!) and to have the messages & errors parsed by jqmvc.
• In case of an error the default controller will look for a rescue page in /Views/[ControllerName]/Rescues/error.aspx or /Views/Shared/Rescues/error.aspx (or .ascx in case of an ajax request). You can specify your own rescues for different types of errors by using the RescueAttribute of
• You should remove default.aspx if your application-server supports wildcard mappings.

I also made up a nice(r) way to inject the ViewEngine into the BaseController. It’s now injected through a public method using a MethodInjection attribute:

Thanks to this method, we no longer have pre-register all the Controllers with our container (in the previous version of jQueryMvc I scanned all dll’s on ApplicationStart to register the Controller and assign the ServiceViewFactory as the default ViewFactory)

Furthermore, since the ASP.NET MVC team decided to change the way the Views are rendered (now through a ViewEngine, which is nice I think), it was no longer needed to use the code from Aaron Lerch. Though still inspired by his code ofcourse, I removed almost all of his code now. We now have a single ‘ServiceViewEngine‘ inheriting from the ASP.NET MVC’s default WebFormViewEngine. All code deciding what view to render, is now located in this class.

What I did not like about preview 2, is that the name of the master-template cannot be set from within the ViewEngine. It’s now stored into the ViewContext, and the setter is private . So now the mastertemplate is set in the BaseController, causing the BaseController to have to know what type of request the current one is (which is bad):

As usual, you can download the hottest source from the Subversion repository at http://code.google.com/p/jquerymvc/source/checkout or you can download a zipped package of the source code.

A view days after I created my sample project that added some jQuery magic to the ASP.NET Mvc Framework, Aaron Lerch wrote an interesting article.

He used a ViewFactory to do the json-serialization and added XML serialization as well. I liked this approach better then using masterpages. I took his code, altered some bits and created a library called jQueryMvc with it. This library also utilizes the MvcContrib project. It’s now even easier to make your ASP.NET Mvc project ajax-enabled with jQuery, it just requires 4 steps:

1. Add a reference to jQueryMvc.dll
2. Make your global.asax inherit from JqueryMvcApplication
3. Add <%= Ajax.RegisterJqueryMvc(Page.ClientScript) %> to the <head> section of your (master)pages.
4. Let your controllers inherit from BaseController

That’s it, your all set. You should take a look at the SampleSite that’s included in the download on how to use the utility. Using it works almost the same as the previous version, so if you haven’t done so, you should read my previous article. The only difference is the exception handling. Since I decided to embrace the MvcContrib project, the exception handling for ajax & html requests have changed. Exceptions are now handled with a [Rescue] attribute. The BaseController has a default Rescue attribute attached which leads all exceptions to the "error.aspx" rescue handler. So your project should at least have /Views/Shared/Rescues/error.aspx that outputs the exceptions for your site. If you want to catch specific exception for yourself, you can add a rescue attribute to your site that catches that error type. E.g. if you want to catch a SecurityException, you could add

If an exception of type SecurityException is thrown during a controller action execution in your HomeController, MvcContrib will look for /Views/Home/Rescues/security.aspx and if that doesn’t exist, it will look for /Views/Shared/Rescues/security.aspx. The viewdata for those pages will be the exception itself. The rescue attribute can also be used on method level.

Another nice thing is that the MvcContrib is build to use Inversion of Control (IoC). BUT!: if you don’t want to do anything with IoC for now, you can leave it where it is! jQueryMvc just uses it for attaching the ViewFactory to your controllers, that’s all you need to know. You can also stop reading just here, the rest is about the dependency container that I used.

For jQueryMvc I choose the Microsoft Objectbuilder framework for this, although, with MvcContrib, you’re free to choose an other framework. I choose the ObjectBuilder, since I’m the one that committed that to MvcContrib

In JqueryMvcApplication, when the application get’s initialized, we’re looking for all controllers in the currently running project.

All these controllers are registered with the Dependency container and our custom ViewFactory is also registered with this container. The ObjectBulderControllerFactory makes sure the controllers are fetched through that very container, and when that happens, the ViewFactory is attached to them.

There are also some  nice helper functions in JqueryMvcApplication, for making the registration of your own services/helpers/etc into the container a breeze.

I’ll talk about using the container in some other article sometime.

For now, have fun with jQueryMvc.

Downloads

• Project at GoogleCode
• Download source, binaries & sample project
• View online demo of the sample site

• Load views through ajax (with back-button support)
• Do ajax-style form-posts and retrieve only the messages, errors and updated content
• Do json form-posts and retrieve the errors and messages as a json object

Here are the quicklinks for all you people who don’t want to read the story.

• View online demo
• Download webproject
• Download Visual Studio template

For all you people who want read about it before playing around, here’s a little intro to the code…

The project contains a BaseController, which should be inherited by all your controllers. This controller (ofcourse) overrides the System.Web.Mvc.Controller and handles the detection of Ajax requests and/or Json requests. It does that by overriding the Execute method and reading some http-headers. Unfortunately reading http-headers is the only (evil) way I know to detect this.
Fortunately, while I was playing with this project, I saw that Michael Schwarz posted exactly (well, 99%) the same solution as I figured out, so for now I’ll take this as the best solution until someone provides me a better one.

As you can see, there’s also some error handling in here. If there is an exception thrown during the controller execution, it’s wrapped in a simple class called SimpleException. This class is easily serializable, so it can be passed on as a javascript object to the browser, in case of a json request.  In case of a non-json request (either normal or ajax), the default error handler called "error.aspx" in views/shared/ is rendered.

The BaseController also overrides the RenderView. In the RenderView, we do some special stuff if the request is a json- or ajax-request.

If the current request is a json-request, the template "json.aspx" is called upon. The default "json.aspx" is located at /views/shared/json.aspx and the only thing it does is serializing the current ViewData.

One special note is that in the codebehind, I had ‘strong type’ the ViewData to an ‘object’, since the ViewData class doesn’t allow us to serialize the real object.

Then there are the 2 masterpages: ajax.master and site.master. Both of them contain 4 ContentPlaceHolders:

• Errors
• Messages
• maincontent
• dynamiccontent

Errors and messages should ofcourse output the errors and informational messages for the current request. I created a handy extension method on the HtmlHelper to quickly output these:

The maincontent should contain the entire page without the usual MasterPage stuff (eg navigation). The dynamiccontent should only contain the content that can change during the same request (eg. the ‘hello {name}’ part in the demo).

In case of an ajax request, the javascript adds a querystring to the request telling what content is requested (either maincontent or dynamiccontent) and the ajax.master decides what to output for that request based on this querystring:

Ajax links are very easily created, also through an extension method:

The first parameter is the text of the link, the second one is the action on the controller and the third one is the id of the container-div.

The other client functions are all form related, you an see them in use in the /views/home/index.aspx template:

You can use any of these methods to submit your forms, just use them as you like it. The methods can be found in /Content/mvc.js

Well that should be enough talking about code, just go ahead and play to find out the rest by yourself.

Messing around with it, and looking at samples of others, I see the controllers tend to get quite messy. Where normally the codebehinds got messy, it’s now moved to the controllers.

Let’s say we’re using Subsonic
as our data-access layer and we have created this controlleraction:

[ControllerAction]
public void List(string foldername)
{
    ICollection folders = GetFolders(userId);
    bool hasInbox = false, hasDrafts = false, hasSent = false, hasBin = false;
    foreach (PrivateMessageFolder folder in folders)
    {
        hasInbox = hasInbox || folder.FolderType == PrivateMessageFolderType.Inbox;
        hasDrafts = hasDrafts || folder.FolderType == PrivateMessageFolderType.Drafts;
        hasSent =hasSent || folder.FolderType == PrivateMessageFolderType.Sent;
        hasBin = hasBin|| folder.FolderType == PrivateMessageFolderType.Bin;
        if (hasInbox && hasDrafts && hasSent && hasBin
            ) break;
    }
    if (!hasInbox)
    {
        folders.Add(CreateSystemFolder(PrivateMessageFolderType.Inbox, userId));
    }
    if (!hasDrafts)
    {
        folders.Add(CreateSystemFolder(PrivateMessageFolderType.Drafts, userId));
    }
    if (!hasSent)
    {
        folders.Add(CreateSystemFolder(PrivateMessageFolderType.Sent, userId));
    }
    if (!hasBin)
    {
        folders.Add(CreateSystemFolder(PrivateMessageFolderType.Bin, userId));
    }
    PrivateMessageCollection messages = new PrivateMessageCollection();
    messages.LoadAndCloseReader(SPs.GetMessages(foldername, UserId).GetReader());
    PMData data = new PMData
    {
        Folders = folders,
        PrivateMessages = messages
    };
    RenderView("List", data);
}

Now, while this works perfectly fine, it’s messy. It’s messy because now my controller is very dependant on how subsonic works. So if subsonic changes in the future, or I choose to pick another dataaccess layer since subsonic support has stopped(or whatever reason), I have to rewrite all my controllers! Not nice, not nice at all.
It’s also messy because I can’t see at one glance what my controller is passing to my view. I have to actually understand the code to see what it’s passing on.

Now look at this peice of code:

Daos.PrivateMessageDao privateMessageDao = new Forums.Daos.PrivateMessageDao();

[ControllerAction]
public void List(string foldername)
{
    //load the collection
    PMData data = new PMData
    {
        Folders = privateMessageDao.GetAndEnsureFolders(UserId),
        PrivateMessages = privateMessageDao.GetMessages(foldername, UserId)
    };
    RenderView("List", data);
}

All code that has been removed, is now in the privatemessagedao

To me, its quite clear what this is passing on, it’s very clean code. I moved all the data-access parts to the Dao. So the dao (or service, or what ever you want to name it) contains the logic that’s needed to retreive, update, delete, etc. The controller shouldn’t even care how that dao does that, it just needs the POCO‘s.

In our example, we also have folders to be created by default. This is by no means the responsibility of the controller, the controller should just tell something else that it needs those folders, that’s it. The other thingy should create them.

Now we have seperation of concerns, so we have the possibility of using Dependency Injection for accessing the dao (and others), but I’ll write about that some other time