>>>>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 ;-)

Hi,
I wasn't referring to any IDE abilities. Your 'onion' analogy is only part of the MVVM pattern. It also relies on the ability to work with views that are purely declarative which pretty much brings it down to WPF, Silverlight and (maybe?) HTML5. A VM for a WPF front end would be useless for a WinForms or ASP.NET implementation - you could use the same model but everything else would have to be replaced completely.