I've been writing data-driven web apps since 1995, and it didn't take long to realize that the web UI sucks. As I heard Tom Eberhard say in a recent conference session on the topic of chosing winforms or webforms: "The Web was never designed or intended to be used for normal data driven application UIs."  If you think about the early efforts of Tim Berners-Lee at CERN, Andreeson with Mosaic at NCSA, and others, the web was never about data-driven applications. But that's not my point of contention with web apps.

It's the UI, dweedlehead. Users have long had to suffer with marginally functional web widgets, like the drop down list, for instance. And forget about a simple combo box! Yeah, yeah, there are smart guys out there with incredibly cool hacks like Andy Smith whose work is excellent and who I really respect, but you're still putting a silk purse on a sow's ear with this sort of approach.

Which is, of course, where .NET Winforms comes into play.  Okay, I'm done preaching to the choir. This post is to cover my approach in moving existing web applications to a winforms future.

Again, thanks to Tom , I "got it," and have been building truly logical layers, keeping the UI layer tightly tied to the UI (currently web forms and web controls), building a business class layer for ALL non-UI logic, and a fully separate database layer. In other words, I am building every web app with the idea of replacing it with a winforms front end, so I am constantly thinking how to build it for today's web requirements and yet easily upgrade it to a winforms app.

A few self-imposed design enforcements are:

1) The business layer holds ALL non-UI logic.  All of it.

2) Public class objects reside in the business layer to which data can be easily passed from either a web UI or a future winforms UI.

3) The UI layer never talks to the data layer directly without first passing through the business layer. Never. If I need to populate a dropdown, for example, I have a public DataTable GetWhatever() business layer method which simply (for current web-based apps) returns the public DataTable GetWhatever() datatable from the data layer method of the same name. It seems redundant, but this way, the business layer can be easily uncoupled from the data layer if, in a future winforms extranet scenario to replace the current web-based app, I need to call a Web Service-based data layer.

Another result of this approach is how much cleaner and more, uh, logical the code is in each of the various layers.