我是否有理由使用 Knockout MVC 而不是 Knockout JS? [英] Is there a reason I would use Knockout MVC instead of Knockout JS?

问题描述

另一位用户建议Knockout MVC 来处理一些 AJAX 发布问题.我读了一点，我发现它是 Knockout JS 的包装器.所以我想知道两者之间的真正区别是什么?我是否应该为 Knockout JS 而烦恼，因为 Knockout MVC 存在吗?我什么时候会使用一个?

Another user suggested Knockout MVC to handle some AJAX posting issues. I read a little on it and I see it is a wrapper around Knockout JS. So I wonder what are the real differences between the two? Should I bother with Knockout JS since Knockout MVC exists? When would I use one over the other?

推荐答案

Knockout MVC 是 WebForms 的私生子.它通过控制器操作路由所有视图模型方法，这意味着发生的一切都必须反弹到服务器并返回.我不明白为什么有人会采用像 Knockout 这样的框架，它旨在成为客户端 MVVM，并强制它为每个功能调用服务器.

Knockout MVC is the bastard child of WebForms. It routes all viewmodel methods through controller actions, meaning everything that happens has to bounce to the server and back. I cannot understand why anyone would take a framework like knockout, which is intended to be CLIENT SIDE MVVM, and force it to call the server for every function.

此外，在服务器上执行这些方法意味着对于每个函数调用，整个视图模型都需要传递给服务器，然后返回给客户端.这太浪费了.

In addition, performing those methods on the server means the entire viewmodel needs to be passed to the server, and back to the client, for every function call. This is incredibly wasteful.

使用 Knockout MVC 意味着为了不必编写 javascript 的好处而牺牲客户端代码的所有性能优势.WebForms 做出了同样的权衡.这不是一个好方法.这是一种反模式.

Using Knockout MVC means sacrificing all the performance benefits of client-side code for the benefit of not having to write javascript. The same trade-off WebForms made. It is not a good one. It is an antipattern.

如果 Knockout MVC 明天就消亡，网络将变得更好.

If Knockout MVC dies tomorrow, the web will be a better place.

这篇关于我是否有理由使用 Knockout MVC 而不是 Knockout JS?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！