>>>I sometimes wonder whether a MVVM pattern would have been better - but trying to compare the two in a web context makes my brain hurt :-{
>>
>>I personally also think the onion metaphore of MVVM is cleaner than the somewhat helter/skelter ways some MVC patterns allow updating the view not only via C triggered roundtrip from M but from C as well, but that battle has been lost long ago and MS had to jump on the MVC band wagon. MVVM being closer to "stateful" might still colour my thinking - the pure fire and forget of classic MVC is hard to beat for statelessness ;-)
>
>I think your last point about statelessness is relevant and made me think a bit more about why MVVM might not be so good.
>
>But if we move away from the idea of having the MS MVC pattern on the server and look at using it on the browser end (with, for example, angular) then MVVM looks good (in fact, arguably, the angular way of doing things IS closer to MVVM) ?

Viv,

IMO moving into territories difficult to discuss - esp. online, where implicit assumptions are harder to miss than in a pub...
I try to view it not as a dichotomy, as MVC with better integrated validation takes on aspects of MVVM. I see a DB-validated and browser validated app, working off a table or range of values as best practive MVC and an app where ***the same*** validation code is running on client (browser), middle (if existing at all) and backend tier as example where the benefits of MVVM (DRY, well debugged) shine. Blurring of such lines will happen if DB backend utilizes the same validation code in JS... And If heavy backend validation instantiates a lot of objects/cursors needed again for the step to create a new V from M, "stateful" becomes a benefit if spoken of as "cached" ;-)
Beauty in the eye of the beholder if the rest of the code is designed in a DRY set of mind and fitting to the actual problem the app needs to solve.