我刚刚阅读了一篇有趣的文章，内容涉及微软似乎正在朝着基于REST界面+基于客户端javascript的Web应用程序的MVVM开发方向发展。
虽然我在技术上理解了这两个模型之间的基本区别，但我对它对我如何编写Web应用程序的影响以及最重要的是如何优雅地过渡到这个新模型感到困惑。
因此，对于从传统的ASP.NET MVC迁移到WebApi + KO的人，会出现以下问题：
答案 0 :(得分：5)
你看到微软开始推动这个“单页面web应用”的事情，部分原因是因为它可以提供更好的用户体验，但主要是因为它使你的网络应用程序迁移到Windows 8原生应用程序要容易得多。
回复：用于验证的不显眼的javascript ...我想说如果你使用Knockout，你就是UI，你的脚本将会如此紧密耦合，即使只是基本的东西，不引人注意的确不是一个有效的目标。您可以在Knockout中进行验证（例如，参见https://github.com/ericmbarnard/Knockout-Validation#readme），但它与ASP.NET MVC的定义不同，并不引人注目Re：单元测试......看看https://stackoverflow.com/questions/6331789/knockoutjs-unit-testing-with-qunit
Re：浏览器兼容...我不知道任何现代浏览器存在任何兼容性问题，除非你有疯狂的用户禁用了JavaScript
答案 1 :(得分：5)
我发现this对于试图通过Knockout网站“不引人注目”的利弊进行了非常好的讨论。
传统上我非常赞成尽可能保持Javascript不引人注意，并且通过我的Knockout表达式，我尝试通过将任何繁重的工作转移到我的视图模型上的函数并创建自定义绑定来尽可能保持最小和整洁它封装了DOM逻辑 - 但我坚定地认为声明性方法本身（例如使用data-bind属性的默认值）在合理使用时是可行的方法。
也许是因为我对Knockout的介绍是我工作的WPF应用程序的Web应用程序“端口”，我的网站的Knockout绑定变得非常接近他们的XAML等价物，因为我学到了更多关于如何优雅地利用Knockout的知识。我只是喜欢能够进行眼球标记，并且能够一目了然地看到关于如何评估视图的真实业务逻辑，而不是jQuery或其他任何物理构建它的细节，以响应在大型灵魂中连接的某些点击事件破坏Javascript文件。
当我重新审视我的一些传统的MVC网站，它利用大量的程序性jQuery来解决问题时，我想，是的，标记是整洁的，但是在6个月之后再回到它，即使我很难理解我的意图是什么所有这些jQuery选择器，回调和DOM遍历。我想如果必须的话，我只会动态地应用Knockout绑定，即如果我的绑定逻辑本身是动态的，那么无论如何，动态模板可能会有所不同。
对于你问题的不引人注意的方面，这是我的2美分，如果你的经验转移到MVVM Javascript过去几个月就像我一样，你就不会回头了。