>>>
>>>I think that certain patterns fit certain technologies better. For example, MVVM makes data binding a breeze and helps with the intricacies of Silverlight.
>>
>>I'd argue that it is the other way around. It's the in-built databinding capabilities of WPF/Silverlight that make MVVM work.
>>
>> MVC makes client-side technologies very easy to use - no so much the architecture itself but the available functionality out of the box.
>>>
>>>Is it really realistic to expect to only use one pattern?
>>
>>It would be a good goal to aim towards.
>>In general terms it obviously make more sense to retain as many layers as possible for all front ends. For example, if I was asked to create a Winforms version of a current WPF app I'd rather spend time making the Winforms UI work with the VM (maybe a generic shim) than writing a whole new tier to link WinForms to the model. And I certainly wouldn't expect to mess with the model :-{
>
>I haven't given this a bunch of thought since Winforms is out of scope, however I would think the only adjustment in the VM would be add some event to the existing OnPropertyChanged event for INotifyPropertyChanged. Winforms won't bind directly to the properties in the VM and an event raised that winforms could respond to update VM properties seems to be needed.
>
>Might be fun to do some play work with this idea, but again with Winforms out of scope for new projects, why.

I was thinking along the same lines but, like you, think it unlikely that I'll be involved with WinForms soon (and certainly not in the context of using it as a front end against existing VMs. Using a VM against straight ASP.NET pages for clients for whom Silverlight was not an option is a more likely scenario.

In either case I don't think the data binding part would be difficult but handling commands might be a bit more problematic.