Let’s say you have a 2 simple classes like this:

Now, in the global.asax’s init (assuming a web application), we can configure NHibernate using Fluent NHibernate like this:

It uses convention over configuration in lots of places, eg the Id property is always used as identity-column if a property with that name exists.
But you could also easily add your own conventions. If you want to have the Id colums to be ArtistId and AlbumId (and any other className + Id), you’d do:

Want to restrict the namespace as well? No problem!

Fantastic! Now, to see what mapping file this code automagically creates for our Artist class, we can run the following code:

which returns an XmlDocument. In this case, the InnerXml of that document looks like this:

Again: fantastic! See how it even generates the one-to-many relation with the correct end-class, because we defined a property IList<Album>!

Running the same code for the Album class gives:

If you want to use Fluent NHibernate the ‘old’ way, you can still add ClassMap<Artist> to your assembly. Hence, you can even mix it with the AutoPersistenceModel! If you have a classmap file, it’ll use that for your class, if it isn’t there it’ll automatically create a mapping for you!

I’m sold! This makes using NHibernate a breeze. You can get up and running with your NHibernate project so much faster now.

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

But I recently ran into strange problems when my appdomain was recycled. When my application starts, it loops through all the assemblies it gets from System.AppDomain.CurrentDomain.GetAssemblies(). This works great when the application starts for the first time, I really do get all assemblies that are in my bin-folder. However, when my worker-process gets killed, the next application start will NOT return all the assemblies in the bin folder. It will only return the assemblies that are used up untill that moment. However, changing the bin folder, somehow triggers a different recycle: this one DOES load all assemblies from my bin folder.

Conclusion: there are 2 types of recycles

• one that does load all assemblies from ‘bin’ into the appdomain as the application starts. And
• one that only loads the assemblies from ‘bin’ into the appdomain as soon as they’re needed.

I didn’t exactly figure out what causes this, and why it is done so. Only thing I could think of (and did) is to check if only my basic assemblies where returned by System.AppDomain.CurrentDomain.GetAssemblies(). If so, I loop through the bin folder’s files and load them all into the appdomain manually. This works and I do have all assemblies again on application-start, but it still is weird imo.

Update: Hmm, more things seem to have changed regarding recycling