I had mentioned model-view-presenter pattern in passing before, because after I saw it it struck me as a pattern that could be a really good solution to having the most decoupling between the UI and, well, everything below it.

The chance came  up to try it during the week on a small project so I gave it a go.

The View was a windows forms app.
The Model was a .NET Class Library with classes that roughly wrapped a set of SQL Server stored procs.
The Presenter was implemented as a .NET Class Library.  This library also contained the definition of the interface that the UI was to implement.

Some of the key advantages of this pattern:

• The actual logic of the application is self-contained so it can be easily unit-tested.  Code that is easier to unit test is easier to get right.
  
• The data layer is self contained and can be unit tested.
• You can implement a couple of different data layers supporting different back-end data stores.
  
• The only code in the UI is just to display the properties on the interface and raise events in the logic layer from the UI.

The key advantage I see for my kind of stuff is that as far as the Presenter is concerned, there is no UI past the interface that it implements.  It would be trivial to replace the Windows forms app with a ASP.Net app that implemented, or to have it feed a serviced componant over remoting, or....