Discworld reference aside, the past week has been pretty intense in terms of application architecture. It all started when my boss initiated a new internal project with the express goal of developing a clean architecture. Model/View/Controller, Service Oriented Architecture and the like.
Now I have a lot of experience developing Windows Forms .Net applications using data binding. I soon found out that Model/View/Controller and Databinding are at odds with each other. MVC says that only the controller should modify the model, the view should merely raise events to the model. Databinding is a two-way process in WinForms, so we have the view editing the model directly. I asked around, and Brian Noyes of IDesign answered:
[Y]ou are correct that data binding features are at odds with a pure MVC model. Basically you are trading off productivity (which data binding gives you) for design purity and explicit control (which MVC gives you).
Brian also pointed out the new BindingSource component in .Net 2.0, which offers more control over data bindings and the changes they make to the model. Incidentally, he wrote a book about Databinding in .Net 2.0, which is available for pre-order on Amazon.com.
I then did some more research, which took me to Martin Fowler's website. I studied Model/View/Presenter and PresentationModel. I dug up Marc Clifton's series of articles on CodeProject, especially the one about an Event Pool. I re-read Omar Al Zabir's article about an Microsoft World-like object model. I really fance the latter because it lays the foundation for automation, a feature of MS Office application that I envy.
After all this reading, I surveyed the battle field. Martin Fowler says that MVC doesn't work too well with designers because they tend to handle events and modify the model in the view. I agree completely with that. One lesson I learned two years ago the hard way is that when you start fighting against your environment, you will lose - but that is another story. The question remains: how to use Visual Studio's bias towards databinding to create a clean architecture?
Model/View/Presenter pulls out all logic out of the view, into the presenter. Very cool, but it falls short in the same areas as MVC: Visual Studio doesn't support Model/View/Presenter either, so it means a lot of boiler-plate coding. Presentation Model still needs a lot of boiler plate coding as well, but it lays the foundation for an object model that supports automation. Omar Al Zabir calls his model an "observable model", but I think it is really an instance of Presentation Model.
Then John Gossman entered the picture. I remembered reading something about Model/View/ViewModel around PDC time, but couldn't find the source. John Gossman started writing a couple of blog entries about Model/View/ViewModel:
I exchanged a couple of E-Mails with John, contrasting MV-Presentation with Presentation Model and MV-ViewModel. I pointed out that one of the benefits Presentation Model is the automation story, and John pointed me to information about automation in WPF. And there was much rejoycing.
To summarize: as of today, there's no ideal solution for smart client architecture that combines both the cleanness of MVC and the productivity of Databinding. Avalon provides much better support for it, as also mentioned in the book by Chris Sells and Ian Griffiths.