>>>Did you mean MVVM ?
>>>If so then that refers to a similar pattern but optimised for WPF (in fact it's not well suited at all for anything else).....
>>
>>which negative sides do you see ?
>>IMO conforming to a onion-like model is a plus - a view accessing both model and controller,
>>which is allowed in standard MVC, feels less clean in the architecture sector.
>>We had MVVM similar fwk back in 2000 - was workable...
>
>To my mind, things like WPF's command routing and control templates (with databinding) are a natural fit for MVVM. At one point we looked at how well an MVVM VM could be made to work with, for example, a WinForms or ASP.NET front end. The answer seemed to be 'not well'.

If you speak of less/no support from MS wizards/DB designers, I clearly concur.
But from pure architecture, I'd disagree. The article (thx for the link) agrees with my mental shorthand classification for MVVM
as unidirectional pure onion (only outside layer knows next inner layer) which IMO is best for a wide range of apps.

Sometimes MVP's bidirectional access from P to V might be needed, but very often can be simulated via properties on VM/P.
I still think it is a better mold than MVC - but in MS manner implementation/wizard details fog the issue while giving dev support ;-)

regards

thomas