>>>>>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) ?
>>
>>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" ;-)
>
>AFAICS, if you want server and client side validation with ASP.NET then you have to repeat yourself (once in C#, once in JavaScript) although for a straightforward MVC app the helpers will do it for you. ISTR that with node.js you can use the same javascript on the server side as well - but that's another story.

I have not kept up on the myriad of possibilities to run ECMAscript in MS serverside of things, but would reccommend hightailing out of Dotnet if you were FORCED to repeat code the validation once again in C# (unless specific parts need a speed boost). I remember Rick writing a few years ago about hosting some JS for JSON, there still is the old JScript, there was at least an attempt of reimplementation via dynamics (IronJS), some support for Node.js and I have read about a bridge to V8 - probably a few others under my radar. Will gladly say that having no clear, separate target implementation of ECMAscript in view of the move to HTML5 for GUI is puzzling - in java world there are clear favorites like Groovy, Rhino or Jython always available if you drop their .jar and a few different implementations marshalling to CPython for instance.

On the MVC side: Reading about JS functions being available in MongoDB or via V8 integration module inside PostgreSQL probably is enough for most sites even under Node.Js and Meteor - while not totally integrated like VStudio perhaps easier to bend to your needs and/or not that much dependant on Seattle bandwagon of the year...