Hi: I'm just starting my blog. On that note I'll just begin with a stream of consciousness on client side architecture. Florian Krush's Kool Xaml Blog is a great place to catch up on some cutting edge .Net ideas especially if you are interested in WPF and client stuff. Speaking of WPF based clients there aren't very many to choose from at the moment. Yahoo Messenger is a notable exception and apparently much but not all of the Microsoft Expression product line uses WPF.

One of the lead developers is a fellow named Dan Crevier. Basically most of us programmers are aware (the client side ones at least ) of MVC Model View Controller as one of the basic architectures for writing GUI code. I won't go into details here but it's about having layers and a separation of concerns ( isn't it always ) with the recurring theme of not mixing the code up so much that it's hard to maintain and impossible to change. With WPF the V part (view) is inherently factored if you are using XAML and data binding. The reason why is you are no longer writing imperative code ( plain old code ) and instead using a DSL Domain Specific Language to specify the View part of an application. While this starts you down the road of writing UI (ignore the design part for now, just focus on arch ) in a modern fashion it by itself will not provide enough arch to keep you out of trouble. However when you use XAML there is frequently code in code behind files to support the WPF objects in the view. The presence of the code behind files serves as a de-facto ViewModel in that it's the controller logic for your View in many cases. For example it's common to have Command Bindings in the window's code behind file. This is a layer violation so now you can't test the application without the View code. In fact you have no application without the View. In other words you are mixing the model and the view code together in the code behind file(s).

This is an excerpt from Martin Fowler's Supervising Controller piece: Supervising Controller

Many UI frameworks provide the ability to easily map between the view and model, often using some kind of Data Binding. These approaches are very effective in allowing you to declaratively set up a relationship between elements in the view and model. Usually, however, there are more complex relationships which require you to have more complex view logic. This logic can be hard to manage, and in particular hard to test, while embedded in the view.

So now enter Dan Crevier and his excellent posts on DM-VM-V allow you to design your way out of code behind files. If you are interested in client arch this is a great place to start especially if you are using WPF.   http://blogs.msdn.com/dancre/archive/tags/DM-V-VM/default.aspx

All of this is kind of driving towards this goal of the headless application that can be tested exclusively of the user interface. Contrast this with buying test automation tools that actually drive the user interface from scripts. That is the old way of doing things.