MonoRail Routing Upgrade Coming

I just did an update from the Castle repository, and look what I found:


Looks like we may be seeing improved routing capabilities in MonoRail soon. Isn't open source grand?

Castle MonoRail vs Microsoft MVC

Everyone seems to be chiming in on the newly announced MVC framework from Microsoft. A lot of the posts seem to be very positive.

The most talked about features seem to be:

• Routing


• Mockable IHttpRequest/IHttpResponse


• Type-checked views

The routing feature seems pretty nice, but how far is MonoRail from having this feature? I think that MonoRail is missing this feature mainly because it wasn't developed in the era of IIS6.

IIS7 as I understand it gives the web application access to the web request earlier than IIS6, which gives it more control over the routing capabilities. Currently, IIS6 is not really well suited to be able to handle routing requests when there's no file extension on the URL. I imagine that this feature could be added fairly quickly once there's more motivation and more adoption of IIS7.

The mockability of IHttpRequest and IHttpResponse is a pretty nice feature as well, but couldn't MonoRail do this? Scott Guthrie said that they didn't change ASP.NET at all to get this feature.

Couldn't MonoRail wrap the standard HttpResonse and HttpRequest objects with adapters that implement a similar interface? The major hurdle with this seems to be that this wasn't done in the first place, and there's a lot of code out there that would have to change to use the new interfaces.

I have to admit that type-checked views sound enticing. It would be pretty cool to have refactoring operations automatically change things in the views.

But I've lived in a compiled view world and I really don't want to go back. If I have to recompile my project because I changed something in the view I would be pretty annoyed. It's already a huge annoyance to have to wait for the AppDomain to reload when I change something in a controller. I really don't want to wait for it to reload when I change a view as well.

I remember back in my Java/Struts days, I welcomed a switch in our project to Velocity over JSP files. There was a huge increase in productivity and I really didn't miss the type checking at all.

I love being able to submit a patch or jump on the Castle mailinglist to discuss a quick change that would help my own project and have the change implemented within hours or days. Wouldn't you lose that ability if you switched to Microsoft's MVC?

I guess that's a standard issue when deciding between open source and commercial frameworks. I'm really not ready to give that up, and I think that's one of the main reasons I'll be sticking with MonoRail as long as the project remains as active as it is.

Overall, I am pleased with the announcement. It seems that Microsoft is watching what is going on the community and trying to deliver a better platform for developing web applications.

My main point is that MonoRail is already a great platform that's in use by many, it's actively developed, and I'd be surprised if this new platform from Microsoft doesn't push it to greater heights. As always though, I'll be keeping an open mind as things unfold.

Unexceptional Dictionary Accesses in C#

Take a look at this:

            Dictionary<string, string> dictionary = new Dictionary<string, string>();

            dictionary["Hello"] = "World!";

            Console.WriteLine(dictionary["Hello"]);

            Console.WriteLine(dictionary["Goodbye"]);

What's the output of this code? You might think that you'd get the word "World!" followed by a blank line, but that's wrong. You get this big hairy exception:

System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.ThrowHelper.ThrowKeyNotFoundException()
at System.Collections.Generic.Dictionary`2.get_Item(TKey key)

I don't really like that exception at all. I find that it's usually quite unexceptional for something to be missing from a dictionary. You might think it would be nice to get a null back instead of getting an exception. I might agree with you. OK, but maybe they had a reason for making the dictionary behave this way. Think about this situation:

            Dictionary<int, int> dictionary = new Dictionary<int, int>();

            dictionary[1] = 2;

            Console.WriteLine(dictionary[1]);

            Console.WriteLine(dictionary[2]);

Now, what do you think? Still want a null back? Integers aren't reference types, and you should never be getting null when something is supposed to return an integer. You might think that could just return default(T) but in this case the return value would be zero. But, zero is a perfectly valid number so it probably would have been a bad design decision to have the dictionary return default(T). So we're left with this exception.

You might attempt to fix this by guarding all your dictionary accesses with ContainsKey() checks like so:

            Dictionary<string, string> dictionary = new Dictionary<string, string>();

            dictionary["Hello"] = "World!";

            if (dictionary.ContainsKey("Hello"))

                Console.WriteLine(dictionary["Hello"]);

            if (dictionary.ContainsKey("Goodbye"))

                Console.WriteLine(dictionary["Goodbye"]);

There's a few of problems with this approach, however. First of all, it looks ugly, and it's really verbose. What if you're retrieving a large number of values from this dictionary? All those ifs get really tedious, and there's more potential for error when you're providing the key twice to the dictionary. Also, there's a potential race condition here. What if another thread removes the key from the dictionary the instant after you confirm that it is in fact in the dictionary, and then try to retrieve the value for the key? You're going to get an exception. And yet another problem is that this solution is inefficent. The dictionary has having to perform the work to lookup the key twice instead of just once.

So if you can't guard the dictionary access with an if, how can you safely determine if a key is in a dictionary and retrieve its value while avoiding a race condition? Well, they thought of that. That's why they created TryGetValue(), which basically works like this:

            Dictionary<string, string> dictionary = new Dictionary<string, string>();

            dictionary["Hello"] = "World!";

            string value;

            if (dictionary.TryGetValue("Hello", out value))

            {

                Console.WriteLine("Dictionary has the key!");

                Console.WriteLine("The value is " + value);

            }

            else

            {

                Console.WriteLine("Dictionary doesn't have the key!");

            }

So this solves that latter two problems of the three problems I mentioned above about the guard clauses, but it really exacerbates the first problem of verbosity. So how can we fix this? What if you really just want to get an null back if the key was missing from the dictionary? As mentioned before, you'd only want to do this if your value type was a reference type. How would you get about it? You could create a helper function like this:

        public string GetValueSafelyFromDictionary(Dictionary<string, string> dictionary, string key)

        {

            string value;

            if (dictionary.TryGetValue(key, out value))

                return value;

            return null;

        }

Or more generally:

        public TValue GetValueSafelyFromDictionary<TKey, TValue>(Dictionary<TKey, TValue> dictionary, TKey key) where TValue : class

        {

            TValue value;

            if (dictionary.TryGetValue(key, out value))

                return value;

            return null;

        }

So this could definitely helps cut down on the verbosity, especially if the value from dictionary is supposed to go into the property of another reference type instead of some variable on the stack. But it's quite annoying to have to keep passing the dictionary, so let's make this better:

    public class DictionaryValueGetter<TKey, TValue> where TValue : class

    {

        private readonly IDictionary<TKey, TValue> _dictonary;

 

        public DictionaryValueGetter(IDictionary<TKey, TValue> dictonary)

        {

            _dictonary = dictonary;

        }

 

        public TValue this[TKey key]

        {

            get

            {

                TValue value;

                if (!_dictonary.TryGetValue(key, out value))

                    return null;

                return value;

            }

        }

    }

OK, this is a lot better. Take a look:

            Dictionary<string, string> dictionary = new Dictionary<string, string>();

            dictionary["Hello"] = "World!";

            DictionaryValueGetter<string, string> valueGetter = new DictionaryValueGetter<string, string>(dictionary);

            Console.WriteLine(valueGetter["Hello"]);

            Console.WriteLine(valueGetter["Goodbye"]);

And this will work with any dictionary where your "value" type is a reference type, which is perfect because that's the only time this solution makes any sense. We could have gone further than this solution and provided a full implementation of IDictionary that provided all of this behavior, but I think that was a bit too much work for my simple use case.