Jeremy D. Miller -- The Shade Tree Developer

I am using Presentation Model. UI testing is just about impossible, so I just use tests against the presentation model. I checked out NUnitForms at one point, but the pain/reward ratio was too high. Maybe it has gotten better since then, but this project is on hold for the moment anyway. In an ideal world no one should be writing windows forms. :)

-James

We are using the Supervising controller approach.  We have also taken a SOA style (not using actual web services) approach for our separation of layers.  We found that going the services route makes the code simpler and a little easier to test.

Testing the UI is our hardest part i would say. We test our presenters, but there is no tests to ensure that the wiring between the presenter and the view is actually correct :(?  

You know what, I was trying to get my head around M-V-VM and always wondering what exactly it is.... Presentation Model it is, of course!! Thanks for the enlightment :)

cheers

Florian

Whatever you do - do NOT try using typed datasets with the databinding thats given to you out of the box - it flat out doesnt work unless your doing a - select * from Northwind style demo.

I still haven't come up with a satisfactory cross-window state mechanism that doesn't degenerate into either tramp data or huge parameter lists. I definitely think it's time for a pros/cons article about the various architectures.

Automated testing I've found to be easy - WinForms is so easy to reflect on and navigate that a simple custom scripting system that runs from within the app makes 90% of UI testing possible to automate.

It's interesting you mention menus - I find for menus, toolbars, trees, etc, the designer just gets in the way - so much nicer to have (say) menu structures in resource files, reflection-linked to command classes.

The most successful technique I've used so far is making use of property and validator classes in business objects, and attaching them to custom data-bound controls (ignoring the built-in stuff). With that system in place, most simple forms didn't need anything more than an initialization function that attached properties to controls.

Memory management I found (ironically) got to be tricky in the end - if someone forgot to detach an event handler or similar, it's very difficult to work out what object graphs are sitting around in memory. The SciTech Memory Profiler was a great tool for that as it has a memory diff/delta function.

- Stu

I'd describe the architecture of the app I inherited a couple months ago as "the Italian kitchen".

> What are your challenges?

Getting the VS designer to work. In my experience it's way too fragile, especially once you introduce third party controls (which you inevitably have to on large Winforms apps).

> Lumping everything into the Form's because you don't see the need for MV*?

How's this for lumping everything into the form: the app I've been pulled onto has a form which contains an entire business layer, data service and caching service *sob* I'm putting together an MVP+CAB+WPF based architecture on the side. God, I hope it is as compelling as I think it will be.

We try and centralise as much as possible into the object model layer - validation with attributes + base virtual method, persistence via an in-house OR framework (written before NHibernate!!), some UI elements such as hints, decimal places etc also in attributes on object model properties.  

Then in the UI layer we have forms for editing each concrete type.  The form is subclassed from a base form and the type is declared in a static member.  We drop custom controls onto the form and set the property names.  A controller wires up the controls to the form's object at runtime and handles validations etc.  Each control has a set of standard actions, which can also be extended.  These work out of the box by calling into a dialog factory to, say, edit a linked object.  Loosely MVC, I guess.  

The controls are also authorisation aware, the rules being configured into the app, users in groups etc.  So, if you aren't allowed to read access to a type in a link control on a form, the control disables and does not display the item (actually, the item doesn't even get there!).

We've found this to be fast to develop apps and works nicely.

I am working on a mid-size winform project. Your series helped me a lot. I choose to use JPBoodhoo's style of MVP (passive view?), using events to communicate from view to presenter.  

MVP challenge - getting everyone on the same page.

Unit testing challenge - the reaction that "we have spent time learning MVP already, now you want us to write unit test and slow down our progress"...

The good - it's flexible and well organized, you know where things should go.

WinForm Challenge - winform provides too much freedome and developers just want to do crazy things drawing everything they can. Everyone should read 'About Face' before they work on any winform projects.

@Harry, +1 on the 'About Face' recommendation.

The app (Windows XP Embedded) I'm currently on is basically Designer Orientated Architecture.  The new stuff that I'm adding to it is basically following a Supervising Controller pattern.

Challenges:  Just the typical ones you'd expect with legacy code written with no unit tests.  That, and client has this distorted perception of how long things take (i.e. you're just binding to a data control, why does it take so long?).

Passive View MVP here.  Prior to using passive view we were using NUnitForms to test the UI.  NUnitForms was great but it was extra work when our UI changed a lot.  When we changed to passive view the UI layer was thin enough we decided not to do any automated testing on it and our tests became easier to write and faster to run.

I don't really have any major issues with it.  Coworkers without Resharper might complain about all the extra interfaces and layers of abstraction it added over the previous method.

My team and I are using MVP passive view for all new development but... we are strongly considering MonoRail.

I'm tackling a small-ish project using the Smart Client Software Factory (SCSF) built over CAB so it's an MVP application. I've added polish with DevExpress controls and plan on putting together a web version for a follow-on. Oh yeah, it's gotta occasionally connected clients as well and be deployable using Click-Once.

Could you put your nav bar on the left rather than the right? On Firefox, the text in your articles flows under the nav pane, which means I have to copy and paste and lose formatting in order to read anything.

Also, forgot to mention I gave up on the home-grown data layer code generation I was doing in favor of EntitySpaces.net - $150 and I'm done, would've taken much longer to enhance my stuff to support the same level of features (SQL CE, dynamic SQL instead of sprocs, etc.). Challenges are/were finding a GREAT text-book, blue-print best practice for how to do things with SCSF/CAB and handling the occasionally-connected aspect of it. Ain't gonna use datasets so that's out - pure OO back to the data layer.

Correction: on the main page, the margins seem to be off for every article that starts before the nav column ends. Probably one of those minor CSS incompatibilities between browsers. This only affects the main page, though.

Oh, man. Here goes.

We used to just throw everything into the form because we basically didn't know any better. At this time we're just trying to wrap our heads around the other approaches (your BYOCAB series helps a lot, but stuff is still missing).

We've settled into something pretty much resembling a supervising controller MVP, only our Model is now a bit of a problem. We're one of those Microsoft-only shops (reasons don't matter right now) and we don't have anything other than the naked framework. So we're stuck with databinding, TableAdapters and all the rest. Some of those are problematic already, and those who don't probably will turn out to be in a few weeks.

Our most pressing problem is fetching data, representing it and passing it through tiers. Without a ORM, our best bet for fetching is stored procedures that yield datasets. Then we can either pass the datasets around or build some other kind of entities from them. But then we don't always need the whole entities, but rather some kind of view on them ("give me these properties of that entity matching those filters, and also the number of child entities it has and the name of the CategoryID its bound to, but I don't want the category itself...").

Currently, this moves us into very strange presentation models coming from the service layer, and database views for serving presentation views, which lights up the BAD COUPLING neon sign. We don't really know what to do from here.

The fact that it's a WinForms application over WAN doesn't really contribute to our side.

Help. Please.

Supervising controller is my preference.  However, I've done more than a few ways.  I've found that doing it this way makes my View's interface much cleaner.  It's not proliferated with get/set methods.  This also leads to unit testis for presenters that aren't full of expectations/assertions that a getter was called on the view.  I'd rather just ask the view to give me an object representation before doing a save on the service layer.  IMHO, it's the most pragmatic solution I've seen.

don´t thinks there is a best way, but many. Check this report and you will understand:

www.btleague.net/info.asp

I think I'll call what we have Presenter-Model View with Controllers.  (There is a View and there is a very rich Presenter Model.  There are Controllers too).  

We mostly drop generic container controls onto forms with zero or minimal code, and we have extended properties to be able to bind those controls at design-time.  (The appearance is determined at run-time).  We have bi-directional deep (multiple dots) data binding, which allows the view to be completely driven by the Presenter Model.

The Presenter Model is more than simply a device for binding a form.  It is a first class object in the system, used by security etc.  It enforces Validation.

Underlying that, we have a custom O/R Mapper with integrated support for database structure evolution.

That was all very challenging, but works very well!  Challenges today revolve mostly around supporting newer GUIs that don't fit into the "standard" way we do things.  

That challenge is a direct result of doing the minimal amount of work to get each of the low-level features working (not creating a more general API), and abstracting things to the point at which most developers think they are magic.  The result is that developers can only work in the way that the system is set up, even though it is well enough factored and unit-tested that they could change it (if they knew where to go).

Hey Jeremy,

We're using CAB for our WinForms project.

We use a combination of the three major MVP patterns. Passive View for small dialogs that need to get user input, Supervising Controller for most views, and Presentation Model for data that we have to manipulate before it hits the screen. We have different names for some of the parts in Presentation Model, but it is essentially the same pattern. We use it when we have to map business objects to table-based datagrids, so we map those objects and the important fields with a separate class that generates a datatable as output, and that gets sent to the view.

Pain points:

(1) Validation. We use EntLib for validation, but it only covers about 30%. Most validation is just more complicated and requires more work, especially at the UI level. DateTime is the biggest problem we have, and dealing with controls for it. For instance, our immediate customers don't like the DateTimePicker for data entry, so we had to write our own wrapper around the TextBox control to make it DateTime friendly and allow for them to do fast data entry. I'd prefer to have all validation encapsulated in classes that are just responsible for validation, but when you start databinding controls and dealing with the UI it just gets hard.

(2) Resolution! Our application is written for 1024x768, but we have some users who insist on running their screens at 800x600. Yet, at the same time, they want X amount of data on the screen. So we have a constant battle. Some users (older, bad eyesight) don't want to buy separate glasses for working on the computer. They refuse to change their screen resolution, so we're forced to come up with solutions to have the application behave in a non-standard way, like changing the desktop resolution when they launch the app (what application, besides a video game, does this?), or buying a 3rd party plugin that dynamically redraws all of the application's controls when it detects a smaller resolution (again, why do we have to do this when Windows already handles this?) It's aggravating...

(3) DataBinding and the DataGridView. There's just so many damn quirks. For instance, one of our DataGridViews causes an exception when the user double clicks on the column header, so we have to go in and figure out what causes that and write code to handle that. I mean, why do so many DataGridView features throw so many exceptions right out of the box? It's ridiculous.

The rest of the stuff on your list - dynamic menus, cross screen communication, responsibilities between triad members - we enjoy the benefits of the CAB there. Makes it easy to do all of that stuff.

I just wish WinForms itself was easier to work with; I wish things like DataTime and DataBinding were simpler and easier to use. We spend way to much time tweaking the UI because of things that users consider an annoyance.

We've written our own data binding mechanism. The data binding provided by WinForms is a bit weak (though much improved in 2.0). Our data layer provides a lot of information about fields that has UI considerations such as formatting information, required status, readonly status, etc. (any of these can change based on business logic).

To accomplish this, we've created a comprehensive UI framework. We've inherited all of the Windows controls to expose our binding mechanisms (as well as other functionality) and provide a rich design-time experience for it (we build an ERP product, so the effort is worthwhile).

Recently I have been rewriting our UI framework so that it uses more of a MVC pattern (the Supervising Controller pattern is a close match). The controller exposes the model (our custom business layer) as a property as well as commands (that can be bound to buttons, menu items, etc) and list providers (a way of populating lists in the UI, especially useful for dropdown type controls).

The controller has no knowledge of the UI that is using it. This is important for us because we are hoping to use this new controller layer when we switch to WPF or whatever comes next. This also means the controller can be bound to another UI (sometimes we expose the same model in different views for different types of usage). In order to accomplish this, the UI framework handles all the interaction between the view and the controller.

Another advantage of the controller is that it is testable. Currently we don't have any automated tests for our WinForms. The controller provides a way of testing the logic for the UI and removes the need to test the WinForms themselves (this would only be testing the framework which already has it's own set of tests).

As far as challenges, considering that we wrote our own framework in order to deal with the limitations of the built-in data binding, I would have to say that was our biggest challenge. Within the framework, figuring out how to do all of the design-time stuff (designers, editors, type converters, etc) has been difficult (it's not well documented and, in many places, poorly implemented).

Within the team environment, testing in general has been challenging. It's taken a long time for the team to recognize the value in unit testing and we aren't all quite there yet (creating tests is certainly a skill that must be learned). WinForm testing has been especially problematic.

Hi Jeremy,

We've just started a WinForms (potentially moving to WPF) project here and at the moment, we're using a combination of passive view/supervising controller.

One of the issues right now for us is object lifecycle for presenters and views. Most of the examples online are rather basic, with the view responsible for creating the presenter and passing itself in via the presenter constructor. This leads us to navigation and who is responsible for creating and showing forms etc.

Ideally I would like to see a more complete sample application that deals with multiple forms, application state, complex object databinding to a grid (do you bind to your model or DTOs?) , an events model where multiple views can subscribe to events etc (ie, plug in a USB device and a toast message appears, UI indication changes in multiple forms etc because the device is there). Most samples you see on the internet deal with a single form and text boxes.

I'm using Model-View-Presenter (well, more like Passive View and Supervising Controller, same difference).  Most of our application involves inputting data, validating it, then running it through a calculation engine and displaying the results.  Sometimes the user needs to interact with the results.  Sometimes we save the results (or some parameters of the display of the results).  Luckily, this app is mostly single-threaded.  Here are my pain points:

- Validation: trying to get meaningful (and eventually localized) validation information (error, warning, informational) up to the view from the model layer. (and managing it sanely).

- Designer: Sometimes I find myself working against the forms designer.  It sometimes does things that I'm not sure how or why (Google search helps me figure this out sometimes).

- Thread-Awareness: some third party controls don't understand that you can have multiple message loops running multiple windows in an AppDomain.  The "static" keyword is my enemy when [ThreadStatic] would be more appropriate.  I have a multi-modeless window application that runs in a single process and I'd like to be able to have one window block without freezing up all the other ones.

I'll second what Shannon said as far as a complete example goes. I have read just about everything there is to read on MVP and watched a few screencasts, too. The examples out there are just not complex enough and I end up with more questions than I started with.

Specifically what I have been curious about is change tracking and data binding (complex stuff). Again, I too, want to know what you are all binding to....model or DTO. Right now, we are binding to our model, which is composed of objects made using EntitySpaces (one of the million or so options out there whose implementation uses DataTable under the hood).

The properties on our entities all implement INotifyProperty changed, so testing our models is fairly easy. The biggest problem I have right now is that I have no clean separation between my application layers. Our models expose types from the data layer (EntitySpaces stuff) and we are binding directly to properties on the model. It's easy. It's been very testable so far. But it feels incredibly wrong and makes me feel cheap.

@ J.P.

We bind to the model. We don't use DTO's. Jeremy and others have previously posted about the Wormhole Anti-Pattern. We try and avoid that by using one object from bottom to top. It's not there yet, but close.

We use LLBLGenPro as our OR/M. It maps the database tables to its own entities. But before they leave the DAO we map the LLBLGenPro objects to our business objects (our model). Our client has no knowledge of the LLBLGenPro libraries then. Also, in most cases, we map multiple entities in an aggregate form to what most people would call a UnitOfWork class (we call them "managers" - we wrote these before we really understood the UnitOfWork pattern). The UnitOfWork class is what gets sent back up to the client in most cases.

Our business objects inherit from a base class that we wrote that implements INotifyPropertyChanged and tracks dirty state of the object. If a property gets changed the dirty flag is set to True. Pretty simple stuff. Then we wire up the PropertyChanged event on the client when it gets the UnitOfWork/manager and we use the dirty flag to bold/asterisk a header or other graphical textual element so the user knows when they have something in an edited state (just like Visual Studio when you're editing a code file).

Our collections of business objects then inherit from another base class we wrote that inherits from BindingList<T> and has some custom code. Makes it easy to bind to grids, and we can implement sorting if necessary.

I'd guess that half the time we bind our business collections to grids, and the other half of the time we need to use the Presentation Model pattern because we have to manipulate all of the data and massage it into a table format (DataTable) before presenting it to the user in a grid. Like Jeremy writes above, we then do "subcutaneous" testing on the presentation model class to check each cell's output.

What we've done with our base business object and collection classes is something very similar to what Rockford Lhotka did with CSLA.NET. In fact, I used his code and book as a template, but I wanted my base classes to be way simpler than his, so I wrote our base classes from scratch and reduced the concepts down to just the basics for INotifyPropertyChanged and Dirty tracking.

Push comes to shove I can probably post a complete example. Maybe that's a project for this weekend...

We are using Supervising Controller MVP with binding to the model. Most of the business and validation logic is in the model classes. Our views are communicating to presenters through events. In this approach views are completely decoupled from presenters, but it makes it harder to debug and navigate through code. Also, unit testing is more difficult. We are using NMock 2.0 and managed to write a custom Action to enable event wiring and event raising on a mock view. It works. However, I think I won't use this approach in the next project. I'll let views call presenter methods.

Sadly, we've only just migrated a very large vb6 app to .Net 2.0

Almost a hundred forms, with heavily embedded code and no seperation of concerns.

Despite conversion to .Net, we're still heavily dependent on adodb and vbcompatibility.

Its all legacy code!

Finding somewhere to start implementating some proper OO is mind boggling.

And a rewrite is impossible to justify, it would take too long.

The alternative is to quit and find a proper developer job! ha

@Chris Holmes, @JP, @Shannon

I took an approach similar to Chris and J.P. - like J.P. I used EntitySpaces.net to generate the data layer and (for now) hand-crafted a business entity layer. My approach was to split the business layer into two assemblies - one containing the schema (DTOs) and the other containing the business logic and mapping to the data layer. You can read more about it at my blog post here: geekswithblogs.net/.../114859.aspx

@Chris Holmes

I would love for you to post an example on your blog!

I've tried MVP variations and then decided on Presentation Model.  Really, in WinForms projects, Presentation Model just makes sense with databinding support especially.

Paul Stovell's posts on BOP (Binding Oriented Programming) was an eye-opener for me.  I was like, yeah, I forgot about that feature...

paulstovell.net/.../binding-oriented-programming

www.paulstovell.net/.../searchquery-windows-forms-binding-oriented-programming-example

There is no reason not to use BOP for most of WinForms programming.

I am also trying out events vs. direct method call for communication between view and PM.  I like events since view is completely separated from the presentation but like another poster mentioned, makes it a little bit more difficult to test.

I find that the challenge for me is the lack of a context object.  I recently switched from ASP.NET to WinForms programming and on ASP.NET, you have something called HttpContext that has all your context-sensitive information - user, role, etc.  I didn't know that I'd miss it in WinForms land.  So it's similar to Cross Screen Communication/State issue you mention, and I ended up creating SessionContext class that I instantiate on app startup and be made available everywhere.  But I'm still iffy about this.  How do others access context data?  I know about threadlocal storage, etc. but I'm using CallContext (see blogs.msdn.com/.../AmbientContext.aspx)

@Chris Holmes

I'll second d.s. on wanting to see an example. After I posted last night, I started a small test project that sounds a lot like what you describe. I am thinking that change tracking is not the beast I thought it would be. For collections I have a base class which derives from BindingList<T>. I override OnAddingItem to set my isNew flag. I override RemoveItem to track deletes. And finally override OnListChanged to track changes. Very simple right now, but working. I can at least start to make sense of how this could work in a big WinForms app.

@Jeremy

Yep, that's what we do with application state stuff as well: custom IPrincipal and a service that is injected into classes that need it.

As to the databinding issue, I'd be curious to know in what context are people using databinding. What I mean by that is: are you doing add/edit/delete via the DataGrid, or are you just binding data to a grid and then performing add/edit/delete through another class (probably UnitOfWork)? And are people using two-way databinding on simple properties and controls?

I just finished a large view in our application that displays a lot of different kinds of data and allows the user to edit it (basically an Employee edit screen). Previously we were not using two-way databinding on this view, and it was getting really messy (Passive View, which made it really chatty). I needed to fix an issue with editing DateTime values (our users wanted to do fast data entry and hated the DateTimePicker control, so I replaced it with a custom TextBox for DateTime values). In the process I switched the code over and now all the controls are bound via a Binding object. Changed values are written back to the model during OnPropertyChanged or OnValidating, depending on the particular control and what works best.

Overall I was happy with the change, as it shrunk the code in the view quite a bit. But I'd love to know what other people are doing.

@J.P. & D.S. I'll try and get some code up in the next week or two to show you how we're doing things. Should be a good conversation starter.

After reading your "Build your own CAB" nothing :-)

I think Ayende said that if its painful to use, then there must be better ways to do it.

The essence of you "Build your own CAB" series, must be that nothing is granted, and there is no single way to do it. Just feel the pain, and look to others and see if they have a solution that's (partially) do'able and makes the pain go away.

Because MVC workes in one project does not garantee its success in the next.

So it all comes down to the requirements and how they are best solved.

We're using SCSF and CAB on our front-end, with classes structured primarily as Supervising Controllers.  Our Views use .Net databinding for sync'ing the views with the model.  The state of the model classes from the client gets shipped over WCF down to the app server where it is sync'ed up with the server-side objects and saved mainly using NHibernate.  Some of our other classes are persisted to MOSS (weirdly enough) to facilitate Office 2007 integration and others are loaded from a search engine.  So we have abstracted Nhibernate and our other data sources behind a common set of interfaces.

We're starting to move to a Presentation Model approach for some of our more complex screens that don't map neatly onto our model classes.  We've also adopted a couple of bits of source from the web in order to make our databinding more flexible - BindingListView from SourceForge and ObjectBindingSource from CodeProject.  Before we brought these on-board, the databinding of the views was beginning to drive the placement of properties on our model classes.

Unit tests and integration tests are driven through the MSTest stuff built into VS.  Automated UI testing is done using TestComplete from AutomatedQA.

Pain points: Visual Studio form designer is very flakey.  VS will also occassionally lock up some the compiled binaries and so stop compiling them.  Test lists and VSMDI files in VS are just horrible, but we've managed to avoid them.  WCF is really powerful and flexible, but also immensely complex with an immense number of config settings and extensibility points.  Databinding was becoming quite painful until we adopted the ObjectBindingSource and started bringing in the Presentation Model approach.

I'd also say that we used to have a problem with division of responsibility between the MVP threesome, but that's gotten better since we adopted a TDD approach.  Our dev team is now starting to put code where they can test it, i.e. not in the view.

I`m currently working on a PocketPC device, developing a Compact Framework 2.0 based WinForm app, that`s really a challenge!

I`m using a sort of Passive View approach, with the controller operating on a view *interface*, mocked-up in tests and implemented by a Form class, quite simple so no test is done against it.

hope to blog about this soon..

bye

-papo-

I just throw it all into the Form_Load event... :)

Actually, I'm not sure we really had a "structure" as you defined it. I'm currently converting a VERY linear VB6 app into a .Net app.  So it is providing A LOT of refactoring and then some more refactoring.

One thing I'm trying to move towards is the "Humble Dialog" type.  Don't really know where that falls in all the models above, but that's the goal anyway.  

Sure there's some pain in choosing the right design pattern for the job.

But for me it's mainly the lack of a solid production-quality application shell with a good complement of high-level services.  eg. Eclipse RCP.

Passive View pain: raising events from mocked out view.

Solution: observable view - presenter implements the IViewObserver

pain: Databinding - enough said

Passive View all the way, good choice if you don't to clutter up your presenter with event hooks!

stavo per rispondere a Jeremy , che

I'm surprised to see that no one responded with the Presenter First pattern.

We are trying it out on a new area of our application.  The nice thing about presenter first is that we don't have to develop an entire framework to start seeing the advantages in the new code.

The biggest problem here is acceptance of a different way of designing win form applications other than double click and add code.

I build using the MVP pattern. Maybe you can call it old-school, I don't subscribe to the name splittling Martin Fowler did of it so whatever it *used* to be is what I do. It's mostly user controls or just forms but in some places I'm using CAB (SCSF projects and others where it makes sense).

Challenge wise test automation is a bugger. I'm really trying to get WPF and automated testing working through a Ruby DSL but I think I'm going to have to abandon this idea. No real challenges since everything is in the model and tests work against the presenter. I keep the actual view code to be uber-thin (as best as I can) so that I can swap out any UI I want.

Thanks Jeremy and Chris for your responses.

I am already using StructureMap to inject ambient data (may have to switch to Spring - some politics maybe)

Custom IPrincipal idea is something that I had thought of but didn't know how to go about implementing one.  If you have any links, please do share.

As for the databinding, I really want to see how it pans out.  In my app, each view is pretty small and they combine to make up the bigger view, so I think it may be manageable.  I want to play it out a bit, I think it's a bit too soon to disregard databinding for now.  But thanks for the advice - I'll keep that in the back of my head as we progress.

Hi Jeremy,

Currently, I'm re-engineering an application from VB6 & ASP to .NET C# application. C# app was build before I joined the team. It’s an old fashion code that is written in C#. I have to re-engineer a big part of features and get it done in 2 weeks. I talked out my boss to try TDD in it when I have time.

My question is how I can add TDD in the old app without having StructureMap and breaking the old code. Should I use presenter and let view call it directly?

Thanks  a lot!

Last time I asked the question &quot; How are you building WinForms applications? &quot; just to get

We use Presenation Abstraction Control (PAC) which I am sure is like another controller based architecture out there (most like Hierarchical MVP).  You can google "Presentation Abstraction Control" and find the write ups on it.  It works real well to get different parts of you app talking to each other.

In the last two years I've worked on or built the following:

MVP

MVC

MVPC - As was nick named by people working on it, basically model, view, presenter, controller.

Standard Windows Forms

Standard Web Forms

Currently working on:

ASP.NET MVC - Which I got my first how to up at my blog adronbhall.com/.../6062.aspx

...and some BI/OLAP Apps that I haven't decided on the architecture yet.  But will be doing so very soon.  :)