我想知道为什么不在 ASP.Net 的MVC 4 Web项目中使用静态HTML文件，这些文件使用jQuery+jQuery Templates+KnockoutJS组合使用基于REST（ASP.Net MVC 4 WEB API托管在Azure上并使用ACS保护）。 Web API 可以使用实体框架并返回 JSON 序列化对象，这些对象可以使用 $.ajax（） 检索并使用 KnockoutJS 绑定。
MVC（用于网页）ASP.Net 提供了什么来增加此体系结构的价值？
在我的头顶上，我能想到：
- 多设备支持（设备检测和模板替换）
- 提交数据的服务器端验证（不确定，因为我也可以将验证放在WEB API上？
- 即使我使用静态 html 文件，我仍然可以重写我的 URL（因为我无论如何都使用 MVC ASP.Net）。
有人可以帮助我更好地理解这一点吗？ 提前谢谢。
好问题。我当然发现随着我的 Knockout 项目的进展，我的 MVC/Razor 代码变得越来越少，但我认为我总是会有一些我想在服务器端确定的视图方面。
基本的上下文内容，例如是否在布局页面中呈现已登录/注销的面板，与角色相关的决策，以及应该访问的内容等。我想如果你对你的安全足够小心，并在有人实际尝试做某事时在服务器上实现足够的保护代码，那么你可以在 Knockout 中实现大部分目标，但你最终可能会得到大量的膨胀，迎合视图的每个可能部分。
这可能取决于您的应用程序，但我认为对于大多数 Web 应用程序来说，在服务器渲染时应该确定的内容和应该在客户端上完成的操作之间存在相当常识性的划分。
如果没有别的，您可能希望搜索引擎索引视图中的链接等。如果你在JSON中传递你的"最新10个产品"，并在Knockout模板中使用超链接来渲染它们，那么你就会失去它。
这实际上是一个使用正确的工具来完成工作的问题。
从我在进行淘汰开发后可以看出，它的真正力量来自可观察量和实时 DOM 更新。 这使得客户端应用程序中的丰富界面创建速度更快，更易于管理。 但是，与使用直接的 Razor 页面相比，它仍然更耗时且更难实现。 因此，Knockout JS对于某些应用程序来说是一个优势，在这些应用程序中，大量数据驱动的UI更新需要"ajaxly"进行，但对其他人来说却是矫枉过正的。
如果客户端在这种情况下没有启用Javascript，您的网站将毫无用处，您将无法为他们提供合适的替代方案。
使用MVC 框架和 Razor 语法，您仍然可以构建动态生成的数据驱动内容，而无需使用 jQuery 或 AJAX。 MVC 将为您提供模型和视图之间的关注点的清晰分离，无论您是否启用了 Javascript。
安全性可能是我看到的第一大优势。你仍然有它背后的结构 ASP.NET。是的，确实如此，在您的视图中，您当然可以使用 razor 语法并使用 Knockout 呈现您的视图模型，JSON.NET 使数据绑定比以往任何时候都更容易。最终在未来，也许MVC不会成为未来等式的一部分？（也看看Meteor js，它很酷，而且这种类型的动态模型绑定是JavaScript ATM以外的任何东西都无法实现的。
另外，如果你想看到它的实际效果，我找到了一个很好的代码项目，带有MVC和KNOCKOUT。 http://www.codeproject.com/Articles/424642/Customer-KnockoutJS-and-MVC-demo-using-JSON
在这里，请阅读此内容。引用其中的一句话：
围绕整页加载构建 Web 应用程序已不够好 然后"逐步增强"它们以更动态地表现。 构建快速、响应迅速且现代的应用程序需要您 完全重新思考您的方法。
至于你的问题，MVC 提供了什么来增加 MVVM 架构的价值？将自定义内容迎合到不同的设备可能是一个优势，但您也可以在一定程度上使用 CSS 媒体查询来做到这一点。决定归结为您要从服务器发送到设备的字节数。
您也可以在不使用MVC或WebAPI的情况下进行服务器端验证，并且不需要使用ModelBinder或ModelState.IsValid即可执行此操作。看看像 FluentValidation.NET 这样的东西，它允许你在服务器上进行高度复杂的输入验证，甚至是Web/HTTP层下面的一层。当然，您还希望使用jQuery validate之类的东西来验证客户端。
我同意这里的其他答案，即在服务器（控制器操作或剃刀）级别做一些安全级别的事情更容易一些，也更"值得信赖"。但是这里没有其他人提到MVVM的可测试性。围绕控制器操作或其他服务器端代码编写单元测试非常容易。这并不是说你不能单元/集成/UAT 测试 MVVM 应用程序，只是它需要更多的努力 IMO。