6

我刚刚阅读了一篇有趣的文章，关于 Microsoft 似乎正在朝着 REST 接口 + 客户端基于 javascript 的 Web 应用程序 MVVM 开发方向发展。

尽管我在技术上理解这两种模型之间的基本区别，但对于它对我如何编写 Web 应用程序以及最重要的是如何优雅地过渡到这个新模型的影响，我完全感到困惑。

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

  • 有没有办法使用 MVC + KO 进行不显眼或近乎不显眼（即最少的代码）验证？
  • 如何对他的 UI 代码进行单元测试？
  • 浏览器兼容性是否会受到 KO 的影响？
  • 从一种模型转移到另一种模型时，还有什么其他人需要考虑的吗？
4

2 回答 2

5

您会看到 Microsoft 开始推动这种“单页 Web 应用程序”，部分原因是它可以提供更好的用户体验，但主要是因为它可以更轻松地将您的 Web 应用程序迁移为 Windows 8 原生应用程序。

回复：用于验证的不显眼的 javascript... 我会说，如果您使用 Knockout，那么您就是 UI 并且您的脚本将如此紧密地耦合，即使只是对于基本的东西，不显眼真的不是一个有效的目标。您可以在 Knockout 中进行验证（例如，参见https://github.com/ericmbarnard/Knockout-Validation#readme），但它与 ASP.NET MVC 的定义相同

回复：单元测试...看看https://stackoverflow.com/questions/6331789/knockoutjs-unit-testing-with-qunit

回复：浏览器兼容...我不知道与任何现代浏览器有任何兼容性问题，除非您有禁用 JavaScript 的疯狂用户

于 2012-07-13T19:07:14.760 回答
5

我发现这是一个很好的讨论，讨论了尝试在 Knockout 网站上“不引人注目”的利弊。

传统上，我非常赞成让 Javascript 尽可能不显眼，并且通过我的 Knockout 表达式，我尝试通过将任何繁重的工作转移到我的视图模型上的函数并创建封装 DOM 的自定义绑定来尽可能地保持它们最小和整洁逻辑 - 但我坚信声明性方法本身（例如使用 data-bind 属性的默认值），当合理使用时，是要走的路。

可能是因为我对 Knockout 的介绍是我工作的 WPF 应用程序的 Web 应用程序“端口”，当我了解更多关于如何优雅地利用 Knockout 时，我的网站的 Knockout 绑定变得惊人地接近它们的 XAML 等效项。我只是喜欢能够通过眼球标记一目了然地看到围绕如何评估视图的真实业务逻辑，而不是 jQuery 或任何物理构建它以响应在一个大灵魂中破坏 Javascript 的一些点击事件的具体细节文件。

当我重新访问我的一些传统 MVC 站点时，这些站点利用大量程序 jQuery 来连接事物，我认为，是的，标记很整洁，但是在 6 个月后回到它，即使我很难理解我对所有这些 jQuery 的意图是什么选择器、回调和 DOM 遍历。我想我只会在必要时动态地应用 Knockout 绑定本身，即如果存在我的绑定逻辑本身是动态的情况 - 但无论如何，这可能通过动态模板以不同的方式完成。

这是我对您问题的不显眼方面的 2 美分，如果您在过去几个月中迁移到 MVVM Javascript 的经历与我的类似，那么您将不会回头。

于 2012-07-14T10:50:41.663 回答