So, now that one month is almost up on 2010, I figured that it was time to start blogging about something again.  The first trick to this, of course, was to figure out what I wanted to do in 2010.  It does seem like there will be a lot of interesting things, technically speaking, coming up this year.

A couple of new things I want to look at over the remaining 11 months:

Mobile development, particularly with a focus on Android.  For the latter half of 2009 I have been dabbling in Android.  I believe that it’s time to go out on a bender, and in a drunken stupor get some embarrassing tattoo and join the Android Army.  So far, I’m at two out of three.  Not bad, huh?

Ruby is another technology I’d like to explore – particularly Rails.  I can help but think that the opinionated view that Rails development has taken is the way to go for the bulk of web development.  A lot of websites are basically just forms over data, and Rails seems to address that concern rather well.  To bad nobody around here in Edmonton does much Rails development.

.NET 4.0 and ASP.NET MVC2.  I know there is a lot of debate between Web Forms and ASP.NET MVC.  Personally, I think MVC is the better way.  Probably best to keep abreast of what is going on in the ASP.NET MVC world.  And, of course, the DLR in .NET will come to maturity soon.  By maturity I mean widespread acceptance.  If this happens, then maybe developers won’t get so hung up on languages:  i.e. “I’m a C# guy so VB.NET sucks”.

And finally, a guy needs hobbies.  Now granted, my past hobbies of alcohol and guns (no, not together at the same time) have served me well for the past 20 years or so. However, they are hard hobbies to share with my sons at this point in time.  So, at the start of winter I expanded the geek factor of my sons (and myself) by getting back into Warhammer.  Now the last time I played was about 20 years ago, with the 3rd edition rules.  In fact, I still have some of the books in my basement from back then.  Anyway, picked up The Battle for Skull Pass boxed set.  My son rather likes the Dwarfs.  I suspect it’s because he’s similar in stature/height to the stunties.  Myself, while I find the Greenskins amusing, I suspect I might have to move on and get serious with Dark Elves.

Anyway, enough for tonight.

When you compile, here is what you get:

Compilation failed: 1 error(s), 0 warnings

/home/tom/Projects/MVC-MS-Pl-original/MVC-MS-Pl/Mvc/FormCollection.cs(25,6): error CS0246: The type or namespace name `FormCollectionBinder’ could not be found. Are you missing a using directive or an assembly reference?

Build complete — 1 error, 0 warnings

So, this kind of surprised me.  Looking at the code, I did see the FormCollectionBinder in the code, it’s an embedded class within System.Web.Mvc.FormCollection, check out lines 68-88 below:

   1: /* **************************************************************************** 

   2:  * 

   3:  * Copyright (c) Microsoft Corporation. All rights reserved. 

   4:  * 

   5:  * This software is subject to the Microsoft Public License (Ms-PL).  

   6:  * A copy of the license can be found in the license.htm file included  

   7:  * in this distribution. 

   8:  * 

   9:  * You must not remove this notice, or any other, from this software. 

  10:  * 

  11:  * ***************************************************************************/ 

  12:  

  13: namespace System.Web.Mvc { 

  14:     using System; 

  15:     using System.Collections.Generic; 

  16:     using System.Collections.Specialized; 

  17:     using System.Diagnostics.CodeAnalysis; 

  18:     using System.Globalization; 

  19:     using System.Web.Mvc.Resources; 

  20:  

  21:     [SuppressMessage("Microsoft.Usage", "CA2237:MarkISerializableTypesWithSerializable", 

  22:         Justification = "It is not anticipated that users will need to serialize this type.")] 

  23:     [SuppressMessage("Microsoft.Design", "CA1035:ICollectionImplementationsHaveStronglyTypedMembers", 

  24:         Justification = "It is not anticipated that users will call FormCollection.CopyTo().")] 

  25:     [FormCollectionBinder] 

  26:     public class FormCollection : NameValueCollection { 

  27:  

  28:         public FormCollection() { 

  29:         } 

  30:  

  31:         public FormCollection(NameValueCollection collection) { 

  32:             if (collection == null) { 

  33:                 throw new ArgumentNullException("collection"); 

  34:             } 

  35:  

  36:             Add(collection); 

  37:         } 

  38:  

  39:         public IDictionary<string, ValueProviderResult> ToValueProvider() { 

  40:             CultureInfo currentCulture = CultureInfo.CurrentCulture; 

  41:  

  42:             Dictionary<string, ValueProviderResult> dict = new Dictionary<string, ValueProviderResult>(StringComparer.OrdinalIgnoreCase); 

  43:             string[] keys = AllKeys; 

  44:             foreach (string key in keys) { 

  45:                 string[] rawValue = GetValues(key); 

  46:                 string attemptedValue = this[key]; 

  47:                 ValueProviderResult vpResult = new ValueProviderResult(rawValue, attemptedValue, currentCulture); 

  48:                 dict[key] = vpResult; 

  49:             } 

  50:  

  51:             return dict; 

  52:         } 

  53:  

  54:         public virtual ValueProviderResult GetValue(string name) { 

  55:             if (String.IsNullOrEmpty(name)) { 

  56:                 throw new ArgumentException(MvcResources.Common_NullOrEmpty, "name"); 

  57:             } 

  58:  

  59:             string[] rawValue = GetValues(name); 

  60:             if (rawValue == null) { 

  61:                 return null; 

  62:             } 

  63:  

  64:             string attemptedValue = this[name]; 

  65:             return new ValueProviderResult(rawValue, attemptedValue, CultureInfo.CurrentCulture); 

  66:         } 

  67:  

  68:         private sealed class FormCollectionBinderAttribute : CustomModelBinderAttribute { 

  69:  

  70:             // since the FormCollectionModelBinder.BindModel() method is thread-safe, we only need to keep 

  71:             // a single instance of the binder around 

  72:             private static readonly FormCollectionModelBinder _binder = new FormCollectionModelBinder(); 

  73:  

  74:             public override IModelBinder GetBinder() { 

  75:                 return _binder; 

  76:             } 

  77:  

  78:             // this class is used for generating a FormCollection object 

  79:             private sealed class FormCollectionModelBinder : IModelBinder { 

  80:                 public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) { 

  81:                     if (controllerContext == null) { 

  82:                         throw new ArgumentNullException("controllerContext"); 

  83:                     } 

  84:  

  85:                     return new FormCollection(controllerContext.HttpContext.Request.Form); 

  86:                 } 

  87:             } 

  88:         } 

  89:  

  90:     } 

  91: }

The version of Mono 2.4.3 I have doesn’t compile the class FormCollection because the FormCollectionBinderAttribute is inside the FormCollection class.  This is the bug, and it has since been fixed.  Easy ways to get around this:

1. Just use the binary assembly from Microsoft for ASP.NET MVC.
2. Build your own Mono with the fix included
3. Move the code for FormCollectionBinderAttribute class outside of the code for the FormCollection class.

• StructureMap
• Castle Windsor
• Ninject
• Autofac
• Unity
• Spring.NET
• And probably others that I’m missing.

Ironically, when you first start using an IoC framework, you might find that in trying to make a loosely-coupled, modular, application you end up shackling yourself to the framework you’re using for IoC.

For example, you start off using your own homegrown IoC framework, and then decide at some point in the future to use a different framework, like say StructureMap.  Going through your codebase to make these changes can be quite the exercise in pain.

There are a couple of ways to isolate yourself from this kind of situation.  I won’t get into all of them but instead will focus on the Common Service Locator. What is Common Service Locator?  Well, allow me to cut and paste some text from the web site:

"The Common Service Locator library contains a shared interface for service location which application and framework developers can reference. The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation.”

Blah blah blah – so what does all that mean?  Well, in my own words, CSL is basically a wrapper around your IoC container which separates how you  initialize/configure your IoC container from how you use it.  This separation allows you to use your IoC container without knowing anything about it.

This separation is achieved by use of adapters for the particular IoC container that you want to use.  These adapters are what do the dirty work of finding the service you need, in their own special way and totally transparent from your application code.  Currently, the Common Service Locator has adapters for StructureMap, Castle Windows, Unity, Spring.NET, and autofac.

Now, allow me an example of using the Common Service Locator with StructureMap. There is no special reason as to why StructureMap – it just happens to be what I find myself using these days.

Now, say I use the the following registry to configure StructureMap:

   1: public class DefaultStructureMapRegistry: Registry

   2: {

   3:     public DefaultStructureMapRegistry()

   4:     {

   5:         ForRequestedType<IDb4oConfiguration>()

   6:             .TheDefaultIsConcreteType<SimpleDb4oConfiguration>();

   7:     }

   8: }

In a nutshell this says that every time StructureMap is asked to provided an object of type IDb4oConfiguration, it should instantiate a SimpleDb4oConfiguration object and return that.  So, to get an instance of IDb4oConfiguration with StructureMap, I would do something like this:

   1: var db4oConfig = ObjectFactory.GetInstance<IDb4oConfiguration>();

Pretty simple, but it does kind of tightly couples me to StructureMap.  If I need/feel like/am forced at gunpoint to change my IoC container to something that is Not StructureMap, you can bet that there will be much wailing and gnashing of teeth on my part as I hunt through my code to make these changes.

Now enter the Common Service Locator.  First, let’s take a peek at some interfaces for CSL.  First an interface:

   1: namespace Microsoft.Practices.ServiceLocation

   2: {

   3:     public interface IServiceLocator : IServiceProvider

   4:     {

   5:         object GetInstance(Type serviceType);

   6:         object GetInstance(Type serviceType, string key);

   7:         IEnumerable<object> GetAllInstances(Type serviceType);

   8:         TService GetInstance<TService>();

   9:         TService GetInstance<TService>(string key);

  10:         IEnumerable<TService> GetAllInstances<TService>();

  11:     }

  12: }

The IServiceLocator is an interface that your application will use when it requests something from your IoC container.

Another thing that CSL provides is a static class that your application would use to use a current IServiceLocator to request services.  That static class looks something like:

   1: namespace Microsoft.Practices.ServiceLocation

   2: {

   3:     public static class ServiceLocator

   4:     {

   5:         public static IServiceLocator Current { get; }

   6:         public static void SetLocatorProvider(ServiceLocatorProvider newProvider) {};

   7:     }

   8: }

So, now lets see how we would request the default implementation of the IDb4oConfiguration service using CSL.  First, we would initialize CSL:

   1: var registry = new DefaultStructureMapRegistry();

   2: var container = new global::StructureMap.Container(registry);

   3: var smServiceLocator = new StructureMapServiceLocator(container);

   4: ServiceLocator.SetLocatorProvider(() => smServiceLocator );

What is going on here? Allow me to provide a quick line by line explanation:

Line 1 we instantiate a new StructureMap registry.  We then feed that registry to a StructureMap container in line 2.  With line 3, we see that StructureMap container is then fed to the StructureMapServiceLocator, which is the SM adapter for the Common Service Locator.  Finally, with line 4 we provide a lambda that CSL will use to fulfill future requests for services.

Now when our application wants to get an instance of IDb4oConfiguration it just politely asks CSL:

   1: var db4oConfig = ServiceLocator.Current.GetService<IDb4oConfiguration>();

Pretty simple and clean, eh?  Now, when radical group the Foundation for Unity as the Dominate IoC Container sneaks into your cube and forces you at the point of a nerf gun to switch to Unity, you can do so with minimal disruption to your application. With a properly layered application, it would be as simple as coding a new UnityConfiguration layer and then using that instead of your StructureMapConfiguration layer on application startup.

Now, granted this is pretty trivialized example.  There are other ways to solve this problem, but CSL does seem to take are of the grunt work for you so that you can just get going with things.

Usually when I develop, I write individual tests and then run individually with TestDriven.NET and collectively with Resharper.  In this case, as I was writing one unit test, it kept failing with TestDriven.NET.  At first I thought it was just me being stupid (always a good place to start), and then I was worried that perhaps the documentation for TypeMock was to blame.  So, I sent a email to Avi at TypeMock, mostly expecting confirmation of my stupidity.

Turns out the problem in this case was pretty obscure one (to me).  At home, I do my development in a VM running Windows 2008 64 bit.  When Resharper runs your unit tests, it does in a 32 bit process.  TD.NET, on a 64bit OS,  runs as a 64 bit process.  If you get TD.NET to run as a 32 bit process, then your tests will run fine under TD.NET.

To do so, from the Visual Studio 2008 Command Prompt, change to the directory that you have TD.NET installed in.  Then use corflags:

corflags /32bit+ ProcessInvocation.exe

Note that it’s probably best to do this when logged in as the Administrator.

I will say that I was happy with the support I got from the guys (Avi, Gil and Ohad) at TypeMock.  Given the fact that we’re about a half a world apart (western Canada vs. Isreal), they provided prompt, excellent support.  My thanks to them.

Usually when I develop, I write individual tests and then run individually with TestDriven.NET and collectively with Resharper.  In this case, as I was writing one unit test, it kept failing with TestDriven.NET.  At first I thought it was just me being stupid (always a good place to start), and then I was worried that perhaps the documentation for TypeMock was to blame.  So, I sent a email to Avi at TypeMock, mostly expecting confirmation of my stupidity.

Turns out the problem in this case was pretty obscure one (to me).  At home, I do my development in a VM running Windows 2008 64 bit.  When Resharper runs your unit tests, it does in a 32 bit process.  TD.NET, on a 64bit OS,  runs as a 64 bit process.  If you get TD.NET to run as a 32 bit process, then your tests will run fine under TD.NET.

To do so, from the Visual Studio 2008 Command Prompt, change to the directory that you have TD.NET installed in.  Then use corflags:

corflags /32bit+ ProcessInvocation.exe

Note that it’s probably best to do this when logged in as the Administrator.

I will say that I was happy with the support I got from the guys (Avi, Gil and Ohad) at TypeMock.  Given the fact that we’re about a half a world apart (western Canada vs. Isreal), they provided prompt, excellent support.  My thanks to them.

Castle Monorail has been around for much longer, three years or so?  It’s still listed as a release candidate on it’s website, but I’d say Monorail is suitable for production.  Currently, I am not aware of any projects in the Edmonton that are based off this framework.

I guess this is anecdotal evidence that you won’t get fired for sticking with Microsoft.

The two frameworks have quite a few similarities.  IIRC, in Austin last fall Scott Guthrie did mention that the ASP.NET MVC framework was influenced to some degree by Monorail.

Regardless, it’s good news.  Personally, I like both frameworks, and would prefer either of them to Web Forms.  YMMV.

Client side, the user would click on a button in their browser, in order to "check out" or "check in" – pretty simple stuff.  Click a button, update a record in the database.  I wanted this done via AJAX, as the page itself is pretty heavy with data, and I didn’t want to go through the whole page lifecycle.  I spent some time Googling how to do this on the web, but I didn’t find anything that seemed to be suitable for something as simple as this.

So, enough boring stuff, on with the issue.  In my current application the ASP.NET web service that the client should call looks something like:

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

[ScriptService]

public class CampaignProductCheckoutService : WebService, ICampaignProductCheckoutService

{

  [WebMethod]

  public void CheckIn(int campaignProductId, int loginId)

  {

    // Do something...

  }


  [WebMethod]

  public void CheckOut(int campaignProductId, int loginId)

  {

    // Do something...

  }

}

Pretty simple webservice, nothing fancy.  Here is the corresponding Javascript on the browser:

$.ajax({

  type: "POST",

  url: "CampaignProductCheckoutService.asmx/CheckOut",

  data: "campaignProductId=3&loginId=4",

  beforeSend: function(xhr) {

    xhr.setRequestHeader("Content-Length", "campaignProductId=3&loginId=4".length);

    $("#progressBarContainer").show();

  },

  dataType: "xml",

  complete: function (xhr, msg) {

    $("#progressBarContainer").hide();

    if (xhr.status == 200) {

      alert("Happy Times!");

    }

    else {

      alert("Wailing and gnashing of teeth!");

    }

  }

});

This looks busy, but in reality, it isn’t. Now, for a detailed explanation of what is going on here, I’d suggest reading the book jQuery in Action.  It is a most helpful book for learning jQuery.

Anyway, here is a quick rundown of what is going on:  the $.ajax is a jQuery method that will perform the AJAX call, using the parameters that we provide it.  jQuery will perform an HTTP post to web service specified in url.  As part of the POST request, you can see that we’re passing in the parameters for the webservice call.  So far, pretty straightforward.

The next line, beforeSend, is a javascript method that jQuery will call before it does the POST.  In this case, we make sure that the request header has the length of the data being sent, and we show a progress bar to the user.  The funny syntax you see there is how we select the DIV element holding our animated gif and display it to the user.

Your standard ASP.NET web service will return XML to the client, and we inform jQuery of that with the dataType parameter.

By default, jQuery will perform the AJAX call asynchronously, so in the final line we provide another Javascript callback.  jQuery will call this function once the request is finished.  In this case, we hide the DIV element holding the progress bar, and we check the XMLHttpRequest object that is returned from jQuery. If the status is 200, then all okay and we display a happy message.  Otherwise we assume the request failed, and display a sad message to the user.

There you have it, a quick and dirty explanation of using jQuery to call an ASP.NET Web Service.

Rod uses a custom code-gen solution based heavily on sprocs – a data driven approach.  Sounds like it works well for him.  Oren concurs that this technique could be very effective in certain circumstances.  It will have problems with complex situations that deal with convoluted/difficult data scenarios.  He’s giving an example, but I just can’t keep up with him.  The point of Oren’s story is that a domain driven approach will would better when you’re not dealing with data but with data and behavior.

Brad Abrams brings up the point of noun centric vs. verb centric  designs.  Noun centric == data driven.  Verb centric == domain driven.

Oren talks about one of the big advantages of DDD.  We can very easily change the model, as it is all in code.  Tools like R# allow us to make changes quickly, and then NHibernate will allow us to update the database just  as quickly.  Databases are an implementation detail, part of the application, a mere persistence store.  A good domain design will generally lend itself to a  decent database design.

Apparently it is possible to suffer from an SQL injection attack with NHibernate.  According to Oren, you have to be pretty stupid for this to happen, but it can happen.  I did not know this.

Topic changes:  what do you do when you come to a client who has 1.5TB of established data and database.  How do you deal with that?  Ideally, you claim ownership of the data, and carry on.  This isn’t very realistic.

Oren starts explaining that NHibernate can allow you to partition the data in existing databases to match your model.  He suggests that it might be better to speak with the DBA to make a new model, as this approach might take a lot of effort.  Might be smarter/better to change the persistence.

Oren’s preference is to generate the HBM’s by hand.  He wants the pain to be real.  The logic is that the pain will force you to thing about your model, and helps you focus on what is important to your model.  By generating the code, you end up with, for example, a domain model that has 200 classes/tables and classes with 700 fields.

Another advantage of using NHibernate:  you get a nice way to set up a unit of work, and can specify boundaries for your application.  For example, you can, via an HttpModule with your unit of work, limit the number of queries (trips to the database).  Oren:  Going to the database is the best place to optimize, not the query itself.  Minimize the trips to the database.  You can enforce this limit right away.  It is not a problem that will hit you out of the blue in production.

NHibernate is very complex, and the learning curve very steep.  Oren argues it is not overly complex, and this complexity allows you to very advanced things.  For the simple stuff, NHibernate is very easy.  It is very irresponsible to just parachute in, introduce NHibernate, and then disappear.

Oren quotes:

• "I tend to be nice to people that pay me"
• "Use a set, that is all"
• "Don’t worry about performance until you see you have a hotspot and are using a profiler"
• "Whoever designed Linq bordered between genius and madman"

Ben Scheirman refers us to Chapter 6 in NHibernate.  Important for collections.

It seems that this session is not so much stored procs, but a Q&A session from the community about what exactly NHibernate can do.  Oren’s knowledge and experience

The CLR is very fast, asserts Oren Eini.  Rod Paddock disagrees.  With WebForms, it isn’t the CLR that is slower, it is all the stuff that goes on behind the scenes with the page lifecycle.

The question is asked:  Are datasets more efficient that NHibernate.  Apparently some people get hung up on these types of things, and claim that tools like ORM’s aren’t good because they add overhead.  Sounds like premature overhead to me.

Unrelated trivia:  This is the latest in the year it has snowed in Seattle since 1968.