There is some "historic growth aspect" perhaps not clearly enough spelled out in my messages to that sub-thread. Data validation at least at public layers IMO is minimum, having the DB check even if the DB is not a (intended) public layer is IMO prudent at least for some types of apps. MVC was defined long before java, browser and JS were born, and grew into the java standard for web apps in times when reusing the JS code (if existing at all) was not possible. MVVM targeting WPF/Silverlight AFAIR put more emphasis on the option to reuse ***code*** in various levels than was usual in [java-typical mostly] MVC at that time. The fact that MVC can reuse the JS code perhaps even with more leverage *nowadays* mentioned as the "blurring" of the historic distinction by using JS-capable backends and JS running or capable controllers by me in both posts.

With the failure to provide Silverlight for the dominant smartphones MVVM was doomed - and MS has been in catch-up mode and not very successful ever since. Or Jobs killed not only Flash by deemphasizing/raising the option to block plug-ins in iOS but prepared the ground to hamper MS plans in that area, as they could not be sure to guarantee the availability of the stack on the client, which is necessary for the finer touches (C# clientside for instance) of the ILM-heavy implementation of the (IMO slightly more elegant, which was what Viv was pondering/thinking about as well) basic pattern/approach.

>You can use Node.js, knockout, breeze, or (insert js flavor of the week) with MVC. You can also use MongoDB with it if you wish. It's long been a best practice to validate data at each public layer of an application. I don't see why it's any different with MVC.
>
>>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...