Friday, February 15, 2008

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.

No comments: