Even so, I’ve sort of been following it from the sidelines for a while and I’m excited to say that Mono 2.4 seems to be a drop-in replacement for the bits of the .NET SDK I was actually using. Now with the release of MonoDevelop 2.0 it seems that I’m also able to get a functioning alternative to the Visual Studio GUI I’ve been using. It’s a colossal achievement and one that makes me even more ashamed. Ashamed that I didn’t think it was possible, and ashamed that I didn’t help out.

To get it working was a bit of a trial though. It turns out that because I already had the default MonoDevelop 1.0 installed that when I started trying to build a new version things got very confused. Not only that it turns out that the build instructions for MonoDevelop 2.0 aren’t exactly correct. After a lot of messing around I think I managed to damage the default installation and cross-link a few libraries here and there. I think if I was doing it again I should probably have followed these instructions Parallel Mono Environments before doing anything. Too late now though. After much building and swearing I ended up uninstalling all Mono environments and then rebuilding everything for Mono 2.4. I didn’t put the Hardy version back yet, I’ll do that if I need to.

Here’s what I did, in case it helps anyone.

First of all I decided that this is a temporary solution and that eventually I would be able to get MonoDevelop 2.0 running from APT, therefore I decided to install everything in /usr/local.

Ubuntu Development Packages

As ever with Ubuntu you will quite probably need to install a bunch of development libraries to make it work. I probably had a lot of the dependencies I needed installed before I began but here are the ones that I didn’t have that I needed. Your mileage might vary.

sudo apt-get install bison  gnunet-gtk-dev libpango1.0-dev libgtk2.0-dev
libglade2-dev libgnome-dev libart-dev libgnome2-dev libgnome-dev libgnomeui-dev
libgnomeprint2.2-dev libgnomeprintui2.2-dev libgnomecanvas2-dev
libpanel-applet2-dev

Mono

As per the parallel environments guide I set up this environment in a script and executed it.

#!/bin/bash
MONO_PREFIX=/usr/local
GNOME_PREFIX=/usr
export DYLD_LIBRARY_PATH=$MONO_PREFIX/lib:$DYLD_LIBRARY_PATH
export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH
export C_INCLUDE_PATH=$MONO_PREFIX/include:$GNOME_PREFIX/include
export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal
export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig:$GNOME_PREFIX/lib/pkgconfig
PATH=$MONO_PREFIX/bin:$PATH
MONO_GAC_PREFIX=/usr/local
PS1="[mono] \w @ "

I then downloaded the following libraries from the Mono 2.4 sources page.

wget http://ftp.novell.com/pub/mono/sources/libgdiplus/libgdiplus-2.4.tar.bz2 

http://ftp.novell.com/pub/mono/sources/mono/mono-2.4.tar.bz2

http://ftp.novell.com/pub/mono/sources/gtk-sharp212/gtk-sharp-2.12.8.tar.bz2

http://ftp.novell.com/pub/mono/sources/gnome-sharp220/gnome-sharp-2.20.1.tar.bz2

http://ftp.novell.com/pub/mono/sources/mono-addins/mono-addins-0.4.zip

http://ftp.novell.com/pub/mono/sources/mono-tools/mono-tools-2.4.tar.bz2

http://ftp.novell.com/pub/mono/sources/mono-debugger/mono-debugger-2.4.tar.bz2

http://ftp.novell.com/pub/mono/sources/monodevelop/monodevelop-2.0.tar.bz2

http://ftp.novell.com/pub/mono/sources/monodevelop-debugger-mdb/monodevelop-debugger-mdb-2.0.tar.bz2

http://ftp.novell.com/pub/mono/sources/monodevelop-database/monodevelop-database-2.0.tar.bz2

Extract all these and then run the below command in each. Because this is a dependency stack you will need to do them roughly in the order they're listed above.

./configure --prefix=/usr/local
make && sudo make install

After that you should be left with a working MonoDevelop 2.0!

Troubles

I encountered a few problems on the way, mostly there were problems relating to not having the correct Ubuntu development libraries and headers installed when the parts of the stack were configured.

I also ran into some problems with the GAC having pre-installed versions of conflicting libraries installed. Eventually though this problem was resolved by uninstalling the default Hardy version of Mono and starting again. Hopefully you won't have this problem because you will have setup a parallel environment in the first place ...

It seems then that almost any user-interface should not violate the principle of least surprise and this is common sense. When I click on a cancel button in a dialog it should not accept my input it should return to where I had come from leaving everything unchanged. This was my first violation this week and it’s a common one, a ‘Cancel’ button in a dialogue did the opposite of what I expected. This was in a popular source control tool (that I won’t name because my version is old and the bug is doubtless fixed now) and it did in fact ‘Submit’ the broken change that I was so keen to cancel. After a short bout of tourrette’s and 5 minutes of trying to figure out how to undo the change I was back on track but my confidence shaken a little.

It’s not just user-interfaces that should not violate the principle of least surprise, APIs shouldn’t violate it either. You know the sort of thing. For instance, a ‘getter()’ should be idempotent and not change any state. Languages like C++ have support for this through the ‘const’ method modifier but I can’t think of another language that I know of that enforces this in the same way.

So I was incensed when I thought I’d discovered an example of such a violation in the .NET framework. I was having trouble using the method Uri.MakeRelative(Uri uri) because I had misunderstood exactly what it did (because I didn’t RTFM) and I expected it to simply strip the routing information from the Uri and return the document path. What it actually does is a more general case and it will effectively ’subtract’ one Uri from the other. Which is more useful when you have things like embedded Uri’s. Anyway, the depth of my sickness isn’t important, the important thing is that I realised that I could have used the principle of least surprise to save me.

As far as I can tell I haven’t ever found a .NET framework method that didn’t do as I expected, that’s partly because of the number of people who use early-release versions of .NET and iron out these problems for me. Thanks! Not only that over the years I have entered into a love-hate relationship with Microsoft. I won’t enumerate the things I hate because disk space is finite but what I really like is the way that M$ have a vast array of tools and products that seem to co-exist with very little problems. This is no small feat, it’s a triumph of quality control and standards and I applaud them.

The conclusion is then, that I should abide and uphold the principle of least surprise wherever possible. Additionally though, I can apply the principle in reverse when I trust the source of the interface to not violate the principle. Moreover if I can succeed in not violating the principle myself then people who use my and my team’s work will have more confidence in it … I can dream, can’t I?

Only thing is your keys aren’t exact, they’re doubles or DateTimes or some such and you can’t use them because you really need to apply a tolerance to those values. What you need is an imperfect hash function.

The solution to this problem is obvious to me now but not so obvious at the time when I was trying to speed up my painfully O(N^2) application. To add your elements into a dictionary and get faster lookup you must obviously include all the elements of the comparison in the Equals() method but exclude the non-exact ones from the GetHashCode() method.

Before I start with this analysis I’d like to apologise to all vegetarians on the planet for eating your friends. Secondly, and more importantly, I’d like to apologise to all decent-folk for producing an example so contrived that it will make you want to vomit. Please pay particular attention to avoid your shoes.

Let’s begin:

public class Beefy
{
    public string    name;
    public double   percentage;

    public override bool Equals(object o)
    {
        Beefy b = o as Beefy;
        if (b == null) return false;
        return (name.Equals(b.name) && Math.Abs(percentage - b.percentage) >= 1);
    }

    public override int GetHashCode()
    {
         return name.GetHashCode();
    }
}

This works by only relying on the string "name" to derive the hashcode. What this means is kind-of subtle and relies on what the Dictonary<T> does to resolve collisions. A collision occurs when two items hash to the same location. Since we know that for Beefy we're not using a unique identifier to place the items into the Dictionary<T> then that dictionary must have a way of coping with the situation that two hash-codes resolve to the same place. Now you would need to check the language you love to find out exactly what it does in this instance. But for .NET 2.0, C# uses a technique called chaining. That is it creates a secondary data-structure which is commonly referred to as a bucket but is really just another list.

Looking at the following diagram, (and again my sincere apologies) you'll see that we have 3 topsides in the same bucket. This happened because the hashcode for the string "Topside" led us to the fourth bucket. Every time we see "Topside" as the name we will end up inserting the Beefy object into its bucket. Every time we want to retrieve a "Topside" we will start at the first element of the bucket and iterate over the chain until we find a match.

In this way then we can get the trade-off we need. Hopefully our inexact matching fields will be few and our exact ones will be many so that we will get close to O(1) performance, however if it all goes horribly badly and every piece of beef we have is "Topside" then we will tend towards an O(N) lookup time.

This started me thinking. Exactly what does this continuum look like? In other words for a trivial class like the one above what sort of read access times would I get searching for each of the 1000 objects in a variety of data structures? Now what if I vary the number of hashcodes between 1 (i.e. everything hashes to the same bucket) and 1000 (where everything hashes to a different bucket) and try to access the same 1000 objects for each hashcode distribution. I performed the process on a Dictionary<T>, my List<T> and a Hashtable, which has a different collision resolution mechanism in C# to the dictionary.

The results were almost as I expected. The Dictionary<T> is faster than the Hashtable because when a Hashtable has an imperfect hash the collisions 'spill' over one another which means that other future values can potentially be mis-placed, not just the current one. However, that performance converges as the quality of the hash improves. Secondly, the way I set up my List<T> the items being searched for should on average be found in the middle (requiring iteration over half of the List<T> to find a single element). You can see that for a very imperfect hash where there are less than 100 distinct hashes in 1000 items, it's better to use a List<T> than either a Hashtable or a Dictionary<T>. At a 90% perfect hash then a List is 22x slower than a Hashtable and more than 50x slower than a Dictionary<T>.

All good news for me because my real hashcode was much more discriminating than that typically sitting above the 90% perfect range. So the List<T> has gone and my hash is meaty sister. Very meaty indeed.

For a long time it seems to me that Microsoft has lagged behind in allowing us to use this idea. Their once flagship product, Visual Basic 6, makes it almost impossible to write good MVC code. First of all, in VB6 there is no real inheritance which makes writing good models difficult. Secondly, if those models should contain any items that generate events then those items can not be defined in a class module and must be made public. Sure you can simulate and work-around these things by various means but in the end you will just be fighting the language. And that is never good.

So it’s good to see VB.NET, or .NET 2.0 to be precise, not only has excellent object support but a mechanism that can be used for MVC is actually built into the language. Someone mentioned to me, before I started using .NET, that you could use .NET delegates for MVC. I nodded my head sagely and life continued unchanged for me. So when it came to actually needing to do MVC in .NET I thought I’d just Google it and that would be that. Several articles came back, but it seems that of the articles that actually worked when I tried them the descriptions about the application of MVC to .NET was more than lacking. In short the articles focused on the event mechanism and that’s all. Whilst this is an important part of the puzzle that’s definitely not all and so this is my attempt. Hopefully mine will be better

To begin with it’s worth mentioning that MVC has to be modified to fit into most modern GUI component frameworks. However, web-based frameworks actually do fit quite neatly into MVC and the approach requires no modification.

The reason that GUI frameworks are a problem is that today’s client GUIs are substantially different from the GUIs of yester-year and these days the framework or OS actually takes up the responsibility of some of the parts of the traditional MVC triad. Unfortunately this is where things often start to go wrong IMHO. People see the obvious benefits of MVC and try to incorporate it into their GUI applications. But as we already said MVC does not, as it stands, fit neatly into component based frameworks like Swing or Windows.Forms.

Some very clever people have thought a lot about this. If you think I’m crazy you should first check out a paper written by Taligent systems: MVP: Model-View-Presenter. If you still think I’m crazy you should read about ObjectArt’s experience with trying to fit MVC (a Smalltalk idea) into their Smalltalk system. If you still think I’m crazy I’ll go and see a psychiatrist.

So a good treatment of MVP is beyond the scope of this post. But I will break down the component pieces as applied to an example and that should probably serve to demonstrate how it could be done and what’s trying to be achieved.

Ok, so let’s have an example and get on with the show. The easiest to comprehend is probably going to be something like an order, which has order items. The presenter adds the items to the order model and the view is then responsibile for showing the order items when they update.

Model
So the model is easy right? Well sort of, it will be the object generating the events since the model triggers the changes into the view component to change contents of dialog boxes etc.

So define a VB.NET class that contains an Event that lookes like a function prototype. And then call it when you want to fire that event. Simple. So …

Public Class Order
    Public Event OrderChanged()
    Private mItems As List(Of OrderItem) = New List(Of OrderItem)

    Public ReadOnly Property Items() As List(Of OrderItem)
        Get
            Return mItems
        End Get
    End Property

    Public Sub AddItem(ByRef i As Integer)
        Dim item As OrderItem = New OrderItem(i)
        items.Add(item)
        RaiseEvent OrderChanged()
    End Sub
End Class

Most of this code is fairly straight-forward. The unusual part was that I defined a variable of type Event which has a function style definition that I subsequently access through a call to RaiseEvent. The way this is going to work is that interested parties in this object will declare an instance of my Order object WithEvents and then also define a public method as Handles [OrderInstace].OrderChanged. When the model raises the event then all the interested parties will be notified.

Not for the first time, though, VB.NET is holding out on us. It has really defined a multi-cast delegate for OrderChanged() behind the scenes which is actually a type. If we were to attempt to port this solution to C# then we would actually need to define and reference the delegate ourselves in that way.

The affect of this is to produce something very similar to the Observer pattern. Where the adding of a new delegate instance calls registerObserver() and the subtracting calls unregisterObserver(). Calling the delegate instance itself will force the analgous notify() method, and this is exactly what RaiseEvent will do.

For the remainder of the model we just need some data-holding for the order item. So lets just add that for fun, no need to discuss.

Public Class OrderItem
    Private mid As Integer
    Public Sub New(ByVal id As Integer)
        mid = id
    End Sub

    Public Overrides Function ToString() As String
        Return Str(mid)
    End Function
End Class

Finally, note that the model also has a contract with the presenter and the presenter is dependent upon it. Therefore the presenter will actually call the AddItem() method as a result of actions made in the UI, more on this shortly. Note that the model should not be dependent upon any other component.

Presenter

The presenter is relatively straight-forward. It is the place where this part of the application lives and is responsible for constructing/managing the view and the model. With the removal of the controller (from traditional MVC) the logic about which components handle which responsibilities is blurred slightly. Since our MVP definition could lead us to put simple controller functionality directly into the view (since the view handles the windowing event queue messages). However, we will try and keep this example pure and have the presenter handle all the model prodding and therefore have the view forward calls on to the presenter when something in the model needs to change. Clearly in a simple example like this the benefit is not clear however larger, more complicated components would benefit from this approach.

Public Class OrderPresenter
    Private mOrderModel As Order
    Private mOrderView As OrderView
    Public Sub New(ByRef view As OrderView)
        mOrderModel = New Order
        mOrderView = view
        mOrderView.Init(mOrderModel, Me)
    End Sub

    Public Sub AddItem(ByVal partId As Integer)
        mOrderModel.AddItem(partId)
    End Sub
End Class

So exactly what did buy us? There’s two answers to this. Firstly by ‘bunching’ our model calls together in a presenter we’ve allowed ourselves to provide the same functionality from anywhere within our application, so we can hook our presenter/model calls up to a button, or a menu with just a couple of extra code lines.

Even better though, is that we can remove this presenter and replace it with a different one if it offers the same contract. To facillitate this we should probably try and place the view/presenter contract behind an interface to make this distinction clear. I haven’t done this here but it would be a simple case of defining an interface that the presenter implements that handles AddItem(ByVal as Integer). A place that this might be useful is, perhaps, when developing presenters that exhibit additional behaviour to the default implementation. For instance when an item is added to an order the ‘auditing’ presenter could additionally write details of the order change to a database or file. Clearly any number of presenters can exist.

View

The view therefore is a subscriber to the Model and is the place where user gestures come in to be forwarded to the Presenter. In this example it is the view for two model objects: Order and OrderItem.

Public Class OrderView
    Private mOrderPresenter As OrderPresenter
    Private WithEvents mOrderModel As Order
    Private last As Integer = 0

    Public Sub Init(ByRef model As Order, ByRef presenter As OrderPresenter)
        mOrderPresenter = presenter
        mOrderModel = model
    End Sub

    Private Sub OrderChanged() Handles mOrderModel.OrderChanged
        ListBox1.Items.Clear()
        Dim i As OrderItem
        For Each i In mOrderModel.Items()
            ListBox1.Items.Add(String.Format("Part id# {0}", i))
        Next
    End Sub

    Public Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        mOrderPresenter.AddItem(last)
        last += 1
    End Sub

    Private Sub OrderView_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        mOrderPresenter = New OrderPresenter(Me)
    End Sub
End Class

Our view, of course, is a simple VB form that has a list box in it that lists the items and a button to add an item. Thus:

You will see that the view handles mOrderModel.OrderChanged() as well as events coming from user gestures. The single user gesture that we handle simply forwards a call on to the Presenter to add an item. Note that this is probably overly simplistic. If this were a more concrete example the view might take user input from a combo box, or some other source, and then actually pass model objects onto the presenter.

Now our implementation contains one additional wrinkle and that is that our definition of MVP states that it’s the presenter that handles the construction of the application model and view. For simplicity’s sake here I’ve actually made the view the application entry point. From there it constructs the presenter and effectively “passes” control over in the expected way. To circumvent this we would need to step outside of VB.NET’s application framework which provides useful functionality so is not done here.

Scaling it up

This idea although complete was only presented on a very small scale. If you were to try and develop an entire application this way things are slightly different. The truth of the matter is that MVP is probably only applicable to largeish projects and attempting to use it on very small applications is probably a waste of time.

So, scaling up means two different things with respect to MVP. The model is a little bit amorphous in as much as it is whatever size and shape it is because that’s the way it needs to be to represent the relationships that exist. The view and presenter though are somewhat different. The view/presenter pair will begin by forming groups of controls and ultimately lead to group other view/presenter pairs. So that the contained view/presenters will receive incoming messages from container views. In this way a form of separation can exist. It makes sense then that the contained components know nothing about their surroundings. Otherwise they can not easily be contained in other components and actually become glued to a specific container.

MVP VB.NET solution