Living in the past

The Chinese have a curse; May you live in interesting times. The 1990s certainly were interesting for programmers. A vast proportion of applications coded during those years were written in Visual Basic and, believe it or not, these applications are still hanging around today.

I imagined that finding a team that programs almost exclusively in a language as crippled as VB6 is in these days of frameworks and massive API's would be rare in itself but it seems that they are not so rare as I imagined. Trying to train such a team to change working practices to encompass .NET 3.x and C# is a challenge.

Over the years I've seen many .NET projects written by VB programmers and it seems that the pattern is always the same. No layers in the architecture, code factored by functions - not by classes, no concept of encapsulation or inheritance, every dirty trick possible to create global objects and globally accessible functionality.

I never realised that object orientation was something that was still on the frontier of programming practices. Maybe the millions of VB devlopers out there really do need help.

On patterns...

I responded to a post in one of the Microsoft newsgroups the other day where someone asked "Is MVC a good pattern to use and should I port my old implementation of it to my new C# application" (I am paraphrasing here).

The answer is; Yes, MVC is a great pattern and NO! don't port it. it's built in to .NET. They just call it databinding.

When pattens became popular in the 90's I was working as a team lead in Stingray's C++ development department and I remember long and fraught discussions about the MVC pattern because my boss saw MVC as somthing that worked on a macro level, the whole view, the whole model and the whole controller. I on the other hand imagined MVC as a light and super granular pattern that only really applied well to individual controls or bits of data. Because he was the boss, Stingray went on to provide an MVC implementation that worked well enough but that encouraged hefty logic built into views and complex interactions with data that sort of spoiled the simplicity and grace of my MVC vision.

Looking at the world now I feel vindicated because databinding is indeed granular and simple and, as I mention in my previous post, is the only thing that Microsoft have really retained between Windows Forms and WPF.

I strongly advise that you don't fall into the trap of trying to reimplement MVC on a .NET platform. I saw an example of this just a short while ago when a very competent and sane C++ programmer was given the thankless task of porting an old C++ program that implemented Stingray's MVC pattern to C#. He spent weeks messing with it and then was disturbed to discover that all that effort could have been avoided with a few simple lines of databinding code.

Powering the presentation layer...

Ok, I know this is a tagline for Infragistics but I think they'll forgive me because they are pals of mine. The thing I'd like to expound today is just what is a "presentation layer"?

In many people's opinion, The guys at Infragistics included it seems, this smacks of UI and graphics. For me however, this couldn't be further from the truth. For me, a presentation layer is totally non-graphic and is really a buffer between the data and the graphical layer.

One thing that I have learned over the last, oh, thirty years in the business is that the graphics always change, it's the data that remains the same. Consider the current situation; We have a world full of applications based on the hype of Windows Forms and the reality of WPF looming, well, more than "just this side of" the horizon. What does this mean for the application developer? Yup, you guessed it, a massive re-write of everything. Or does it?

Over the last little while, I have been working in the financial sector where data is old and entrenched in massive databases. These financial institutions however need up to date applications to run their decades old loan deals. Recently, the emphasis has been on windows forms but now WPF is taking the world by storm and people have been wringing their hands about re-writing all those applications again. On many of the projects I have worked on, the presentation layer has been the key to success in migrating applications to WPF. Here's how it works:

The MVP pattern suggests a model a view and a presenter. This is a great pattern if only people could get the presenter bit right. In implementations such as CAB, MVP is really crippled and has a poor definition but with a little bit of work we can have a perfect system in which the model is isolated from the view by a "presenter" that is really a two-way buffer between the UI and the data. I say two way because the presenter must play the role of a data conditioning filter that runs both ways. Here's a scenario for you.

The database of a bank contains reprsentations of money values. the database actually holds the value of, say, 124,000,000 but, because this is a bank and banks don't deal in piffling small change, when a bank agent see's a loan or mortgage he actually sees the numbers 124.0. Traditionally the conversion between 124,000,000 an 124..0 would be done in the view where some clever code resides. However, if this operation is done in the presenation layer and the presentation layer is databound to, say a textbox in the view, then the presentation layer "presents" 124.0 to the view and when the user types in 125.0 the prsentation layer "presents" 125,000,000 to the data model.

An even better example of this is when the presentation layer synthesizes data. Take for example the need for a number to be of a certain colour. In the database we may see a representation of 100,000,000 that is seen in the UI as 100.0 with a colour of white for the textbox background. When the value is -100,000,000 then that value really should show up in bright red. Where is the colour gnerated though? That's right, in the presentation layer. The UI doesn't have to have business logic in it to translate colours, it just databinds the value to the presenter and the colour of the textbox background to the presenter's synthesized colour data.

So now, what does this all mean for the future? Well, when Microsoft introduced WPF they threw out everything that we knew about UI and replaced it with something else. Well, actually, everything except databinding, which, incidentally, they made more powerful. This means than that if your applications had a model and bi-lateral presentation layer then you could rip out the 10% of code that was your old UI and databind in a shiny new WPF UI in a few days and come up smelling of roses.