I recently hosted the first .Net user group here in town and was pleased to be joined by D’Arcy from the Winnipeg .Net User Group. Afterwards we had a chance to sit down – probably for too long, given his two-hour drive home afterwards! – and talk about everything from past projects to past employers to the impossible fact that we didn’t know each other given how many times our paths have nearly crossed.
We got to talking about design patterns at one point in the conversation and how it was interesting to see some of the emerging patterns and how tightly coupled they were to some of the technologies that we have as developers.
One such instance is how MVVM serves WPF nearly exclusively. Sure, it’s a derivative of past patterns, but this has been very tightly coupled to the WPF experience. So, here’s a technology that, as developers began to share code, helped to surface a pattern.
Then, MVVM was used to create the very tools that designers and developers are using to scratch together WPF applications. Now there are even extensions to VS.Net that allow easier implementation of MVVM (see Karl Shifflett and the WPF Toolkit).
WPF drove the creation of MVVM.
MVVM served as the backbone for tools development.
Now, it’s getting really interesting. Because of limitations in the command binding syntax and underlying framework, the folks on the WPF are actually considering changes to WPF to allow for simpler binding.
Where did this come from? MVVM exposed a need for binding to commands that was not native to WPF. Some of the tools that are being created have features that allow for developers to work around these WPF limitations. The WPF team recognizes this – good on them – and are now updating the framework to improve this aspect of WPF development.
Tech –> Pattern –> Tool –> Tech. We’ve come full circle.
Lather, rinse, repeat.
No comments:
Post a Comment