I'm attending OT2004 conference (Michael Platt is also here and has blogged day 1) and had my first chance to hear Martin Fowler talk.  He did a keynote on MVC Patterns and the role of an Architect in an XP Team.

What is the MVC?

• Model - maintains state
• View - observes state and projects it to the user
• Controller - poked by user events and sends them to the model, which does some domain interpretation

The key idea is to avoid having domain logic inside the UI.  MVC is hardly ever done in the classic way.  There are two ideas inside MVC, one which is popular and one that is unpopular.

Separate the model from the view and the controller
The popular concept is to separate the model from the view and the controller.  The advantage of this is that things are layered, decoupled and separated.  The domain doesn't know anything about the presentation.  This is a Good Habit.

Separate the view and the controller
The less popular concept is to separate the view and the controller.  The original idea was that you could swap our or change the controller.  So if you had a read0only screen you could swap out the controller to ignore user 'pokes'.  The problem is that user controls often combine the view and the control.  A widget can receive input and display the results.  This second concept is often misunderstood and is one of the reasons for tangled descriptions about MVC. 

How MVC was messed up
One reason was the idea of Interface, Entities and Controllers.  The idea is that an interface represented the UI, the Entities represented the domain objects and the Controller was an intermediary that glued the entities to the interface.  The problem with this approach is that the Entities ended up just being structs and all of the behaviour was in the controller which was essentially procedural coding.

A lot of languages are out there but there is a shortage of OO code.  Martin wrote about this in the anaemic domain model - the domain model is just a thin wrapper around data.

Some people have solved this with a service layer.  The idea is that some of the logic associated with talking with other systems that is not wanted in the domain model.  The question is how to mix them.  Martin's view was that it was OK to have a thin service layer, but the key was to avoid having nothing in the domain model.

MVC variations
Based on talking with TW and others, Martin believes that there are two variations to the MVC model.  These are the presentation model and the model view presenter.  The drivers of these variations is testing.  This is another situation where testability has some good effects.

All too often there are two tier architectures where everything is in the view.  Testing in this approach is about driving the application through the UI.  This is too hard to keep updating, the test are fragile and it never works in practice.

So these variations are responding to the need to test without having to rely on the user interface.  One approach is to keep the view so stupid that you don't have to test it.  Another is to put the logic somewhere else.

Presentation Model
One key problem with the MVC model is that the view couldn't be a simple projection of the domain model.  Often you need to alter the data for the user interface.  Sometimes this is trivial, sometimes it isn't.  It's also hard to mix UI widgets with these adaptations.  Also, there is a need to store state that is about the UI and not the model (e.g. is this control disabled, is the text visible?).  Where should you put this in the MVC model?  The change is to have a presenter that is responsible for adapting the domain model for presentation and holds the view state.  It's also responsible for the synchronization with the state of the widget.  In the Presentation Model approach you can ignore the view and test the presentation which works as long as the synchronisation between the presentation and view is so simple.

The MVP Model
The twist in this approach is that the controller can't respond to the user's pokes.  The user pokes the view and the view pokes the controller (named the presenter in this model).  The Presenter tells the widgets to updated and then updates the underlying model   In the MVP model you can use Mock Presenters and test the messages are coming in order.

How do we group as a profession?  How can we improve what we do?
Martin's view is that we should have reflectors who wander around project trying to push our knowledge and practices along.  A lot like Martin really.

Why does XP have no technical lead?
This is where Martin spoke about his observation of David Rice at ThoughWorks and the way he worked as an architect.  He believes there are two views based on how you view the relationship between programming and design.  See his article Who Needs an Architect for more information.

Architects as Controllers
One view is that architects are the ones who come up with what has to be done and the programmers simply implement it.

Architects as 'Guides'
Architects in Martin's view should be someone who is still involved with a project but should be wandering around the team seeing things, making sure that problems are addressed.  Architects should be reactive to problems, and teacher-like helping to mentor the students.

The key for Martin was the architects should stay close to development, lest they become part of a centralized architecture team responsible for process and policy and really haven't developed in a long time.

Relation between XP Architects and User Interaction Architects
Martin believes that web UIs are popular because they are simple to put together and cheap.  Martin's beef with people like Alan Cooper and Interaction Designers are that they don't factor in the cost of designs.  Good Uis are expensive.  Martin handles this in XP by making a simple UI a user story then telling the customer to create another story for a better UI.

What's the link between the MVC and Architect topics?
Reflection.  They key is that Architects must be able to reflect on experience, which is hard.  They should look for what it is being done, decided what is good and bad about it and then communicate that knowledge to a wider audience (sounds a lot like an author doesn't it?)

Martin is a reflector on other reflectors, a sort of meta-reflector.  He mentioned that reflecting on experience is key.  It's the difference between a 9 to 5 job and someone who wants to get the best out of what they do.  Martin left us with the message that 'I have fun, you should look for opportunities to do that too'.