Choosing the Right Presentation Layer Architecture

I wrote an article recently for the Microsoft Architects Journal on choosing the right presentation layer architecture. The two basic choices are smart client and thin client. There are many variations in between, of course, such as using Terminal Services, but I didn't have the space to cover them all.

The basic purpose of the article was to challenge the widely held view that one size fits all - some organization have a blanket policy that says that all applications should be thin client and that is just wrong. Thin client applications have their place, of course, and there are applications which should definitely be architected this way. But to use this approach for all applications can lead to overly complex, pretty unusable applications that cost a lot of money to develop, maintain and extend. This leads to inferior TCO when compared to a smart client solution.

You can of course design an application to provide whatever functionality you want using a smart client or a thin client architecture. The key question is, how easy will it be to do it and how much will it cost? OK, that's two questions. Architectural decisions are about weighing many factors and coming up with a design that provides the best balance between them all. There are a number of issues that keep coming up which can sway a decision on the presentation layer architecture one way or the other and I've tried to capture the most important and frequently discussed ones in the article - things like deployment, reach, offline operation, etc.

Instead of weighing these factors appropriately, some applications are skewed towards one approach and then try to implement a feature which just does not fit with that approach. One of the weirdest things I've seen are thin client applications that are 'designed' to work offline by using a web server deployed to the client. This approach provides the worst of all possible worlds. Not only does the user have the pain of a thin client interface, but the application has all of the problems associated with deploying and updating the web server, application data and web pages to the client. Now that's a square peg for a round hole if ever there was one...

Comments

• Anonymous
  March 03, 2005
  I am at the moment moving a DOS / BTrieve legacy application to ASP.NET / SqlServer - straight port - client wants web forms to act like his dos application - sql data structure is a straight port from btrieve. Client doesn't want any thing else - too hard to deloy - too scared to change structure as it is critical business element - why convert in the first place? Tried explaining to him that this was not the way to taken on new technology.
• Anonymous
  March 09, 2005
  It sounds like a DOS application would be more naturally ported to a smart client application - you'd keep exactly the same structure but implement in Windows Forms. A smart client can be deployed from the server so they'd get a benefit over what they have now right away. Maybe they had other reason's for choosing a web based architecture?