1. An ASP.NET 3.5 Web Forms based website (although #3 below is really the key factor )
2. NHibernate
3. The use of an HttpModule to implement the Open Session in View pattern and provide a Unit of Work implementation (one ISession per HTTP request)
4. ASP.NET web services returning JSON (might well be a problem if the result was XML as well)

In an “old fashioned” Web Forms scenario everything works perfectly. If some unexpected event occurs during a postback then an Exception is thrown and it bubbles up to the HttpModule which rolls back the transaction.

However with a JSON web service (we’re not using WCF so we just have an System.Web.Services.WebService flagged with a ScriptService attribute) when an unexpected event occurs the magic of the framework catches it and the ScriptMethod simply returns the Exception converted to JSON. This was being correctly handled in our UI but because an Exception is not thrown so the HttpModule thinks that everything is OK and incorrectly commits our transaction. And because processing didn’t necessarily finish and our data could therefore get into an inconsistent state (which is even worse than a plain wrong state).

In order to work around this feature I hooked into the EndRequest event in the HttpModule and check the StatusCode of the Repsonse. Here’s the method that I created:

private bool IsAjaxError()
{
  return HttpContext.Current.Response.StatusCode == 500 && HttpContext.Current.Request.RawUrl.Contains(".asmx");
}

Obviously if an error is detected I can take the appropriate action. So if you’re using the above combination of technologies be careful because what you think is happening and what is happening might be two entirely different things.

[SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
   System.Reflection.Assembly._GetType(String name, Boolean throwOnError, Boolean ignoreCase) +0
   System.Reflection.Assembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase) +42
   System.Web.UI.Util.GetTypeFromAssemblies(ICollection assemblies, String typeName, Boolean ignoreCase) +145
   System.Web.UI.TemplateParser.GetType(String typeName, Boolean ignoreCase, Boolean throwOnError) +73
   System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly) +111
   System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData) +279

I knew that some sort of trust issue was the problem and after some Googling I came across this article that explained this problem and more importantly provided a solution. The pertinent command to execute was:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\caspol.exe -m -ag 1 -url "file:////\\computername\sharename\*" FullTrust -exclusive on

Building a UI can be a very database intensive operation in terms of the number of separate calls required. And for each one of those calls the time taken to actually execute the query can be a small compared to the duration of the roundtrip to request and fetch the data. The obvious solution is some type of batching and with Future<T> this happens automagically without any change to the consuming logic (for databases that support it). Let me restate that, you get a huge performance benefit with only a simple change to your query methods in the Repository. So why aren’t you using it?

By default an text box is generated for DateTime fields. What I wanted to do was hook this up to the excellent Datepicker widget from jQuery UI. Here’s how I achieved this:

1. Add the following 3 references to the Master Page:

   <script type=”text/javascript” src=”http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js”></script>
   <script type=”text/javascript” src=”http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js”></script>
   <link href=”http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/overcast/jquery-ui.css” type=”text/css” rel=”Stylesheet” class=”ui-theme” />

   I am referencing jQUery and jQUery UI from the Google CDN (great for getting started quickly as well as for production scenarios). I am also linking to one of the default themes which goes nicely with the default MVC stylesheet.

2. Add the following Javascript to the Master Page:<script type=”text/javascript”>
   $(function () {
   $(“.date-edit-box”).datepicker();
   });
   </script>

   Here I am simply looking for a specific class and attaching a Datepicker widget to it. I am aware that this is not the most efficient approach as the code might run unnecessarily but it’s perfect for a demo.

3. Ensure that the correct class is rendered by the Template. Apparently you can currently only override the default templates for individual Controllers. Therefore create a Views/{ControllerName}/EditorTemplates folder and within it create a file called DateTime.ascx which should contain:

<%@ Control Language=”C#” Inherits=”System.Web.Mvc.ViewUserControl” %>

<%= Html.TextBox(“”, ViewData.TemplateInfo.FormattedModelValue, new { @class = “date-edit-box” }) %>

4. You’ll probably want to use the DIsplayFormatAttribute on the DateTime fields in the View Model to ensure that the time is not also output (don’t forget to set the ApplyFormatInEditMode property to true if you do this).

That’s it. You should now see Datepickers for the appropriate fields that were rendered using the Html.EditorForModel() extension method.

One of the things that I had stopped doing was keeping an eye on various OSS projects to see what was on the horizon. Yesterday I (finally!) started to experiment with NHibernate 3.0. The first thing that caught my eye was QueryOver. As Fabio explained there are a lot of different ways of executing queries in NH. Certainly in the pre-LINQ days ICriteria was the predominantly recommended option because it has elements of type safety to it and its fluent-ish API broke everything down into small pieces and avoided string concatenation hell.

QueryOver is fluent a layer on top of ICriteria. It looks very LINQesque but it’s a very different animal, not least of all because there are some concepts in ICriteria that do not have a LINQ equivalent (caching etc.). In the short to medium term I suspect that it will become my de facto approach for NHibernate queries (I’ve used NHibernate LINQ and it’s great for simple queries but I’ve experienced significant issues with more complicated ones).

What I haven’t figured out yet is how, if at all, this will affect my data access testing strategy. Historically I’ve favored smoke tests that have really been doing little more than verifying that a given ICriteria query was semantically valid. Typically I only resorted to actually worrying about the results in specific cases (mainly due to the burden of maintaining test data for each possible scenario). Then again this sounds like a topic for another post doesn’t it…

On one of the Views I had to move a collection of complex data from the client to the server. By complex I mean more than just a single property. An example of this might be editable rows in a table (yes I know that there are other ways to solve this problem such as using AJAX but please stick with me). In addition I didn’t like the fact that there was a duplication of the presentation logic – server side binding during the initial rendering and client side binding if data was changed. I’ve seen a lot of bugs in the past with this approach when someone makes server or client side changes but forgets about the other piece.

I decided to used JSON as a common currency for this part of the UI. I removed the server side binding. Then on the server side I created a Display Model (a View Model for a subset of the View) to represent the data that I needed to display and edit. I can serialize this to JSON (new JavaScriptSerializer().Serialize(myDisplayModel)). I can subsequently access the JSON via an AJAX request or I can stuff it into the DOM if I am sensitive about the number of calls being made (which I was here). On the client side I used a JQuery plugin ($.evalJSON(myJsonString)) to convert the JSON into a form that is easily consumable in Javascript. I could therefore use the same code to initially populate the UI and deal with any edits.

When an edit was made I simply update the UI and store the new JSON in the DOM ($.toJSON(myJSonObject)). When the form was submitted back to the server I can easily deserialize the JSON (new JavaScriptSerializer().Deserialize<myDisplayModel>(myJsonString);) and then manipulate it as I see fit.

What is nice about this technique is it allows both the client and the server to work with the same Display Model. It also resulted in nice clean “object.Property” Javascript.

As always any feedback or alternative approaches would be greatly appreciated.

One of the reasons that we were keen to work together is that we have a lot of shared values, not least of which are Integrity, Craftsmanship, Agility and Community. However we had not worked together before. And despite our ideological common ground there are always challenges with any new team. One method of visualizing the stages that you typically go through in this scenario is a model known as Form – Storm – Norm – Perform.

I’m not going to explain the concept as the referenced Wikipedia article does an excellent job of that. However I do want to emphasize that any subsequent changes in the team or the context within which it operates take everyone back to the beginning of the process. Of course if the change is small then the duration of the cycle will often be commensurately short. Understanding the process that we were going through and its psychological ramifications has certainly enabled us to be successful. I hope that it helps you too.

(Don’t jump all over me for not fixing the problem myself or the way that I brought up the fact that there was one. We have an excellent working relationship that allows for this type of interaction / humor. And we benefit a lot from it as when the other party can’t be offended you get to the point quickly, agree a solution and move on).

Priyesh (incredulously): How can you be sure that it’s a threading issue?

Jason: Because the error message is “System.Threading.ThreadAbortException: Thread was being aborted”

Priyesh: Ah, you’re probably right then.

Jason: I would argue that the logic that acts upon the collection your iterating over should be moved to a separate method. There’s even a fancy name for this although I can’t remember what it’s called.

Priyesh: I believe that’s called the Law of Excessive Separation!

You’d never guess that Priyesh has a heavy C background!

But support in NHibernate for Sybase is not great. The basics work but some of the more advanced features are not implemented at all or are done poorly. Fortunately we have an excellent relationship with our vendor and have had for many years. Earlier this week they contacted me and mentioned that they will be undertaking an effort to improve their support for NHibernate and were looking for some beta testers.

For this effort they can be commended. It’s also telling (and significant) that OR/M usage is becoming mainstream enough for them to consider this effort worthwhile.

Glenn is going to be leading the effort (as he did for the Java version last year). If you want to influence the direction that we go then please tell us what needs to be fixed.