从传统ASP转向.NET MVC到WebApi + Knockout

Question

我刚刚阅读了一篇有趣的文章,关于微软似乎正在朝着基于REST接口+基于客户端的基于javascript的Web应用程序的MVVM开发迈进.

虽然我在技术上理解了这两个模型之间的基本区别,但我对它对我如何编写Web应用程序的影响以及最重要的是如何优雅地过渡到这个新模型感到困惑.

因此,对于从传统的ASP.NET MVC迁移到WebApi + KO的人,会出现以下问题:

• 有没有办法使用MVC + KO进行不显眼或近乎不引人注目(即最小代码)的验证？
• 如何进行单元测试他的UI代码？
• 浏览器兼容性是否受到KO的影响？
• 从一个模型转移到另一个模型时,还有什么人需要考虑的吗？

Answer 1

您看到Microsoft开始推动这种"单页Web应用程序"的事情,部分原因是它可以提供更好的用户体验,但很大程度上是因为它使您将Web应用程序迁移到Windows 8本机应用程序变得更加容易.

Re:用于验证的不显眼的javascript ...我会说如果你使用Knockout,你就是UI,你的脚本将会如此紧密耦合,即使只是基本的东西,不引人注意的确不是一个有效的目标.您可以在Knockout中进行验证(例如,请参阅https://github.com/ericmbarnard/Knockout-Validation#readme),但它与ASP.NET MVC的定义相同并不引人注目.

Re:单元测试......看看/sf/ask/443225261/

Re:浏览器compat ...我不知道任何现代浏览器的兼容性问题,除非你有疯狂的用户禁用JavaScript

Answer 2

我发现这是一个非常好的讨论,试图与Knockout网站"不引人注目"的利弊.

传统上我非常赞成尽可能保持Javascript不引人注意,并且通过我的Knockout表达式,我尝试通过将任何繁重的工作转移到我的视图模型上的函数并创建封装DOM的自定义绑定来尽可能保持最小和整洁逻辑 - 但我坚信认为声明性方法本身(例如使用data-bind属性的默认值),当合理使用时,是可行的方法.

也许是因为我对Knockout的介绍是我工作的WPF应用程序的Web应用程序"端口",我的网站的Knockout绑定变得非常接近他们的XAML等价物,因为我学到了更多关于如何优雅地利用Knockout的知识.我只是喜欢能够进行眼球标记,并且能够一目了然地看到关于如何评估视图的真实业务逻辑,而不是jQuery或其他任何物理构建它的细节,以响应在大型灵魂中连接的某些点击事件破坏Javascript文件.

当我重新审视一些利用大量程序性jQuery来处理事物的传统MVC网站时,我想,是的,标记是整洁的,但是在6个月之后再回到它,即使我很难理解我对所有这些jQuery的意图选择器,回调和DOM遍历.我认为如果必须的话,我只会动态地应用Knockout绑定,即如果我的绑定逻辑本身是动态的,那么无论如何,动态模板可能会有所不同.

这是你问题不引人注目的2美分,如果你的经验转向MVVM Javascript过去几个月就像我一样,那你就不会回头了.