有没有理由我会使用Knockout MVC而不是Knockout JS？

Question

另一位用户建议Knockout MVC处理一些AJAX发布问题.我读了一下它,我发现它是Knockout JS的一个包装器.所以我想知道两者之间真正的区别是什么？因为Knockout MVC存在,我应该为Knockout JS打扰吗？我何时会使用一个而不是另一个？

Answer 1

淘汰赛MVC是WebForms的混蛋.它通过控制器操作路由所有viewmodel方法,这意味着发生的一切都必须反弹到服务器并返回.我无法理解为什么有人会采用像淘汰这样的框架,这是一个客户端MVVM,并强制它为每个函数调用服务器.

此外,在服务器上执行这些方法意味着需要将整个视图模型传递给服务器,并返回到客户端,以进行每个函数调用.这非常浪费.

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

如果Knockout MVC明天去世,网络将是一个更好的地方.

Answer 2

我刚遇到这个问题,其中有一些非常消极的回答.我要快速加上我的两分钱.

我刚刚开始使用KnockoutJS.由于我正在构建ASP.NET MVC应用程序,因此使用Knockout MVC这样的东西似乎合乎逻辑.在大多数情况下,这似乎是个好主意.我不想花时间<!-- ko -->在我的网页上写javascript和评论,如果我可以使用我熟悉和喜爱的.Net功能来做同样的事情.

话虽如此......是的,目前KMVC存在局限性.将整个模型发送回服务器是一个很大的问题.所以我所做的就是开始自己的淘汰赛 - mvc.这些变化此刻一定是匆忙的.但我现在有能力:

• 创建子上下文(具有完全不同的模型或视图模型的组件)
• 调用服务器时,将模型的选定部分传回
• 期望从通话回来的模型不同于发送的模型
• 围绕ajax呼叫的火灾事件
• 支持更多html5输入类型
• 通过标头将防伪标记传递给服务器(用于ajax调用)
• 可能更多我已经忘记了

我希望尽快回来并真正清理我所做的事情.希望作者将这些更改包含在他的代码中.如果没有,我想我会保持自己的叉子.无论哪种方式,隧道尽头都有光.KMVC可能需要现在的工作,但我相信这个概念绝对值得做.

我当然认为

如果Knockout MVC明天去世,网络将是一个更好的地方.

有点苛刻.

编辑:

我正在查看评论,并再次查看原始问题是什么.完成后我想我应该再添加一点:

首先,最初的问题是我有理由使用Knockout MVC而不是Knockout JS吗？回答/澄清(也许我只是挑剔):Knockout MVC是一个框架,旨在使KnockoutJS与您的ASP.NET MVC应用程序更容易集成.它主要通过使用熟悉的强类型构造来生成KnockoutJS标记.它不是KnockoutJS的替代品.一定要使用KnockoutJS.真正的问题是是否使用MVC淘汰赛也.

话虽如此,作为开发人员,您仍然可以选择何时使用所有可用工具的各个方面.如果要通过向服务器执行完整请求来处理功能的某个方面,请执行此操作.如果要执行ajax请求以检索/更新数据,请执行此操作.如果您想纯粹在客户端执行功能,那么就这样做.

使用Knockout MVC 并不能阻止你充分利用KnockoutJS.使用Knockout MVC 并不会阻止您编写额外的javascript来处理所需的客户端功能.仅仅因为Knockout MVC为您提供了一个快捷方式来生成服务器的ajax回调并不意味着您必须使用它们.虽然,如果你的应用程序曾经持有数据,那么它将不得不在某个时候打电话回家.

与仅使用Apache提供静态HTML和脚本文件相比,使用ASP.NET MVC构建应用程序后端是有原因的.Knockout MVC允许您继续利用这些相同的优势来协助KnockoutJS集成.

Answer 3

我觉得Tyrsius的回答有点过于消极.淘汰赛MVC仍然处于早期开发阶段,但从我所看到的它有一些优势,并且比Webforms的服务器更重要.Visiblity dependancies完全在客户端上获取句柄,只有在使用函数时才对服务器进行调用.在处理复杂的数据结构时,有时需要通过服务器,因此Knockout MVC可能是一种节省自己编写大量Ajax处理的好方法.

确实,它总是来回发送整个模型,这会产生一些开销,而不是自己构建它.但我不会完全把它写下来.特别是当它在将来对复杂的验证进行适当的客户端处理时.

Answer 4

在搜索了一些关于淘汰mvc之后,我发现了这篇文章.虽然我同意浪费网络带宽,但我对这行代码非常感兴趣:

@{
  var ko = Html.CreateKnockoutContext();
 }

这是生成挖空视图模型的一种干净整洁的方式.有没有人使用淘汰MVC只为该功能而没有将所有逻辑移动到服务器端？

Answer 5

Knockout.js的优点在于,您可以通过简单地从服务器来回传递JSON来获得您的应用程序,而无需推送服务器必须大量生成HTML的整个视图.

将它重新放回服务器上似乎非常违反直觉!如果您感兴趣,最好先使用剃刀语法来完成绑定.

我的建议是使用knockout.js进行绑定,以便绑定发生在客户端而不是服务器上,如果这是你想要的目标.如果您希望视图是服务器上的数据绑定,请使用razor.

Answer 6

更多,knockout.js肯定非常擅长客户端数据显示/删除/插入/更新,以及客户端数据计算.如果真正的业务逻辑就像那样简单,我们必须直接应用knockout.js.

事实是,商业逻辑并不总是那么简单.例如,当客户端在视图上插入新记录时,系统可能需要检查用户的身份验证,根据某些业务逻辑或公式等设置新创建对象的默认值...所有这些,无论如何,应该去服务器端并检查基于数据库数据的逻辑.

Developer能够将所有必需的业务逻辑转换为knockout.js视图模型中的java脚本方法.但是这样,设计违反了集中处理业务逻辑的规则.

维护将成为这种设计的噩梦.

总结,什么框架选择真正取决于业务需求.有时,性能不是首要考虑因素.

Answer 7

我还可以看到许多使用Knockout MVC库的好用例.我很难将KnockoutJS集成到我们的MVC网络应用程序中,正是因为@ChinaHelloWorld所指出的原因.以下是一些我觉得非常有帮助的案例.

1. 强类型绑定

我喜欢好的强类型HTML帮助器方法,在设置KnockoutJS时变得完全无用且杂乱.我能做的最好的事情是使用辅助方法的额外参数手动附加我的绑定属性,但我不得不再次使用魔术字符串.我喜欢Knockout MVC提供的帮助程序,用于使用强类型,基于C#表达式的绑定创建输入和其他元素.但是,在这里我想提一下,我想念生成字段的name属性,所以我需要稍微调整一下.

2. 强类型绑定语法(种类)

使用纯字符串绑定时,总是很有可能拼写错误,或者不完全知道您要应用的绑定的正确格式.使用Knockout MVC和VS IntelliSense的流畅API,可以很容易地应用正确的绑定.

3. (几乎)从计算的C#属性到计算绑定的自动转换

只需应用小[Computed]属性,Knockout MVC就可以用正确的KnockoutJS语法生成相应的绑定表达式.我认为这个非常有用.

4. 没有viewmodel代码重复

以经典的方式,我需要在C#代码中使用viewmodel类,然后(几乎)在JS中使用相同的viewmodel代码(带有observables).好吧,这让我很沮丧,当我看到Knockout MVC中使用的技术时,我非常高兴.但是,我需要稍微调整一下,以便能够将它与真正复杂的视图模型(嵌套视图模型,集合等)一起使用,并且能够扩展映射的Knockout视图模型,例如任何需要的自定义JS方法或计算的可观察对象.

所以这里至少有四个非常好的观点.关于viewmodel往返:没有人告诉我们任何人都需要使用Knockout MVC的服务器端处理机制.我也不会使用它,只要有一些复杂的业务逻辑真的需要在服务器上处理.但在大多数情况下,Knockout MVC只是为了简化MVC Views和KnockoutJS的绑定和设置过程.所以我不太明白上面的不好意见.我认为谁写了这些意见并没有花费精力去学习至少Knockout MVC的基本概念.Yout definetely 不应该使用Knockout MVC而不是KnockoutJS,但除了KnockoutJS之外.在任何情况下,理解Javascript和至少KnockoutJS的基础知识仍然是强制性的.

我希望作者继续开发Knockout MVC,因为除了这些优点之外,还有一些功能和改进可以使它更加强大.