另一位用户建议使用Knockout MVC来处理一些 AJAX 发布问题。我读了一点，发现它是Knockout JS的包装器。所以我想知道两者之间的真正区别是什么？既然存在Knockout MVC ，我应该打扰Knockout JS吗？我什么时候会使用其中一个？
问问题
18420 次
12 回答
125
Knockout MVC 是 WebForms 的混蛋。它通过控制器操作路由所有视图模型方法，这意味着发生的所有事情都必须反弹到服务器并返回。我不明白为什么有人会采用像敲除这样的框架，它旨在成为客户端 MVVM，并强制它为每个功能调用服务器。
此外，在服务器上执行这些方法意味着每次函数调用都需要将整个视图模型传递给服务器，然后再返回给客户端。这是非常浪费的。
使用 Knockout MVC 意味着为了不必编写 javascript 而牺牲客户端代码的所有性能优势。WebForms 所做的相同权衡。这不是一个好的。这是一种反模式。
如果 Knockout MVC 明天就死了，那么 Web 将是一个更好的地方。
于 2012-07-23T18:20:39.517 回答
21
我刚刚遇到了这个问题，它有一些非常消极的回答。我将迅速增加我的两美分价值。
我才刚刚开始使用 KnockoutJS。由于我正在构建 ASP.NET MVC 应用程序，因此使用 Knockout MVC 之类的东西对我来说似乎是合乎逻辑的。在大多数情况下，这似乎是个好主意。<!-- ko -->如果我可以使用我熟悉和喜爱的 .Net 功能来做同样的事情，我不想花时间在我的页面上编写 JavaScript 和评论。
话虽如此……是的，目前 KMVC 存在局限性。将整个模型发送回服务器是一件大事。所以我所做的是开始了我自己的knockout-mvc 分支。目前，这些变化必然是仓促的。但我现在有能力：
- 创建子上下文（具有完全不同的模型或视图模型的组件）
- 调用服务器时传回模型的选定部分
- 期望从呼叫返回的模型与发送的模型不同
- 围绕 ajax 调用触发事件
- 支持更多的html5输入类型
- 通过标头将防伪令牌传递给服务器（用于 ajax 调用）
- 可能更多我忘记了
我希望尽快回来，并真正清理我所做的事情。希望作者将这些更改包含在他的代码中。如果没有，我想我会继续使用自己的叉子。无论哪种方式，隧道尽头都有光。KMVC 可能需要按现状进行改进，但我相信这个概念绝对值得去做。
我绝对认为
如果 Knockout MVC 明天就死了，那么 Web 将是一个更好的地方。
有点苛刻。
编辑：
我正在查看评论并再次查看原始问题是什么。完成后，我认为应该在我的答案中添加更多内容：
首先，最初的问题是我是否有理由使用 Knockout MVC 而不是 Knockout JS？回答/澄清（也许我只是挑剔）： Knockout MVC 是一个框架，旨在使 KnockoutJS 与您的 ASP.NET MVC 应用程序更容易集成。它主要通过使用熟悉的强类型结构来生成 KnockoutJS 标记来实现这一点。它不是 KnockoutJS 的替代品。一定要使用 KnockoutJS。问题实际上是是否也使用 Knockout MVC。
话虽如此，作为开发人员，您仍然可以选择何时使用所有可用工具的各个方面。如果您想通过向服务器执行完整请求来处理功能的某个方面，请执行此操作。如果您想执行 ajax 请求来检索/更新数据，请执行此操作。如果您想纯粹在客户端执行功能，请执行此操作。
使用 Knockout MVC不会阻止您充分利用 KnockoutJS。使用 Knockout MVC不会阻止您编写额外的 javascript 来处理您想要的尽可能多的客户端功能。仅仅因为 Knockout MVC 为您提供了一种快捷方式来生成服务器的 ajax 回调并不意味着您必须使用它们。虽然，如果您的应用程序曾经持久化数据，那么它将不得不在某个时候打电话回家。
与仅使用 Apache 提供静态 HTML 和脚本文件相比，使用 ASP.NET MVC 构建应用程序后端是有原因的。Knockout MVC 允许您继续利用这些相同的好处来协助 KnockoutJS 集成。
于 2013-09-17T02:44:13.210 回答
13
我觉得 Tyrsius 的回答有点太消极了。Knockout MVC 仍处于早期开发阶段，但据我所知，它具有一些优势，并且比 Webforms 更轻服务器。可见性依赖完全在客户端获得句柄，只有在使用函数时才会调用服务器。在处理复杂的数据结构时，有时无论如何都需要通过服务器，因此 Knockout MVC 可能是节省自己编写大量 Ajax 处理的好方法。
确实，它总是来回发送整个模型，这会产生一些开销，而不是自己构建它。但我不会完全注销它。尤其是当它在未来为复杂的验证获得适当的客户端处理时。
于 2012-07-27T09:01:09.257 回答
11
在搜索了一些关于淘汰赛 mvc 的信息后，我发现了这篇文章。虽然我同意浪费网络带宽，但我还是被那行代码迷住了：
@{
var ko = Html.CreateKnockoutContext();
}
这是生成淘汰视图模型的一种简洁明了的方式。有没有人使用淘汰赛 MVC 只是为了该功能并且没有将所有逻辑移动到服务器端？
于 2013-03-11T15:33:34.513 回答
8
Knockout.js 的美妙之处在于，您可以通过简单地从服务器来回传递 JSON 来为您的应用程序提供服务，而无需推送服务器必须分块以生成 HTML 的整个视图。
再次将其放回服务器似乎非常违反直觉！如果您对此感兴趣，最好首先使用剃刀语法来完成绑定。
我的建议是使用 knockout.js 进行绑定，以便如果这是您的目标，则绑定发生在客户端而不是服务器上。如果您希望您的视图在服务器上绑定数据，请使用 razor。
于 2012-07-23T18:21:52.023 回答
6
而且，knockout.js 确实非常擅长客户端数据显示/删除/插入/更新，以及客户端数据计算。如果一个真正的业务逻辑这么简单，我们必须直接应用knockout.js。
事实是，业务逻辑并不总是那么简单。例如，当客户端在视图中插入新记录时，系统可能需要检查用户的身份验证，根据某些业务逻辑或公式为新创建的对象设置默认值等......所有这些，无论如何都应该去服务器端检查基于数据库数据的逻辑。
开发人员能够将所有必需的业务逻辑转换为 knockout.js 视图模型中的 java 脚本方法。但是这样的设计违反了集中处理业务逻辑的规则。
维护将成为这种设计的噩梦。
总结，什么框架选择真正取决于业务需求。有时，性能并不是首要考虑因素。
于 2013-11-17T22:04:03.647 回答
6
我还可以看到很多使用 Knockout MVC 库的好用例。我几乎无法将 KnockoutJS 集成到我们的 MVC Web 应用程序中，正是因为 @ChinaHelloWorld 指出的原因。以下是一些我觉得它非常有用的案例。
- 强类型绑定
我喜欢漂亮的强类型 HTML 帮助器方法，它在设置 KnockoutJS 时变得完全无用和混乱。我能做的最好的事情是用辅助方法的额外参数手动附加我的绑定属性，但我不得不再次使用魔术字符串。我喜欢 Knockout MVC 提供的帮助程序，用于创建具有强类型、基于 C# 表达式的绑定的输入和其他元素。但是，在这里我想提一下，我错过了生成字段的名称属性，所以我需要稍微调整一下。
- 强类型绑定语法（种类）
使用纯字符串绑定时，总是很有可能拼写错误，或者不完全了解您要应用的绑定的正确格式。借助 Knockout MVC 的流畅 API 和 VS IntelliSense，应用正确的绑定真的很容易。
- （几乎）从计算的 C# 属性到计算绑定的自动转换
只需应用小的 [Computed] 属性，Knockout MVC 就可以以正确的 KnockoutJS 语法生成相应的绑定表达式。我认为这个也非常有用。
- 没有视图模型代码重复
以经典方式，我需要在 C# 代码中拥有 viewmodel 类，然后（几乎）在 JS 中拥有相同的 viewmodel 代码（带有 observables）。好吧，这让我很沮丧，当我看到 Knockout MVC 中使用的技术时，我感到非常高兴。但是，我需要对其进行一些调整，以便能够将它与真正复杂的视图模型（嵌套视图模型、集合等）一起使用，并能够使用例如任何需要的自定义 JS 方法或计算的 observable 扩展映射的 Knockout 视图模型.
所以这里至少有四个非常好的点。关于视图模型往返：没有人告诉我们任何人都需要使用 Knockout MVC 的服务器端处理机制。我也不会使用它，只有当确实需要在服务器上处理一些复杂的业务逻辑时。但在大多数情况下，Knockout MVC 只是为了简化 MVC Views 和 KnockoutJS 的绑定和设置过程。所以我不太理解上面的不好的意见。我认为写这些意见的人并没有花精力去学习至少 Knockout MVC 的基本概念。你绝对不应该使用 Knockout MVC 代替 KnockoutJS，但除了 KnockoutJS。在任何情况下，理解 Javascript 和至少 KnockoutJS 的基础知识仍然是强制性的。
我希望作者继续开发 Knockout MVC，因为除了这些优点之外，还有一些功能和改进确实会让它变得更加强大。
于 2013-12-11T17:46:52.717 回答
4
在 .Net MVC 模式中，视图模型已经用标签“@model yourmodel”清楚地标记到每个视图/部分视图中，这可以指导开发人员了解在该视图中将做什么。
使用 knockout.js MVVM 模式时，您可能不会看到任何 .Net 视图模型，除了视图中的“data-bind”等标签。这将使视图和控制器解耦，并且难以为团队中的新开发人员专门跟踪逻辑。
我相信knockoutMVC可以解决这些困难，节省大量的javascript代码，这些代码会使系统难以维护和理解。
由于 knockoutMVC 使设计仍然坚持应用服务器端视图模型，因为它是 C# 代码，因此易于跟踪和维护。
对于一个商业项目，经理应该始终专注于易于开发、易于维护、易于升级、易于理解和快速交付以赚钱。
牺牲一点性能但让它变得简单，客户端和服务器端的一致性应该是一个关键点。Javascript 是一个很大的维护问题。
将整个视图模型发送回服务器端真的很重要吗？如果是这样，我们可以将一个大模型拆分为几个小模型。
于 2013-11-17T18:28:24.023 回答
2
如果你不使用 komvc 生成的函数，你仍然有性能。正如 Nigel 所说，初始页面生成仍然必须由服务器生成。您始终可以在客户端添加用户脚本并创建不需要返回服务器的功能。它是一种工具，可为开发人员提供一点生产力。与 Web 表单在性能上的比较肯定被夸大了。伙计们，这是一种可以帮助您按时完成任务的工具。
于 2013-10-16T17:37:00.137 回答
1
I will add my 2 cents in favour of knockoutjs, though it is little complicated to write compared to knockout MVC, the benefit you get is huge when it comes to re-usability. The client code can work harmoniously with other technologies as well.
Keeping aside the security perspective I personally feel knockout js is a way of complicating asp.net MVC and it should be used as is (knockout js) with pure RESTful applications such as asp.net webapi.
于 2014-03-27T11:58:02.330 回答
1
Knockout MVC 是 ASP .NET MVC 的强大扩展，它允许您使用开发人员友好的 fluentAPI 直接在您的 .NET 项目上实现网站客户端功能，无需 Javascript 并删除大量重复和重复的代码。
淘汰 MVC 与编写 ASP .NET MVC 剃须刀相同，您可以轻松获得客户端功能。
您不必编写视图模型和绑定代码行。
我一直在我的大多数网站上使用 koMVC，开发时间减少、易于维护和最小的学习曲线是一个巨大的回报。
我建议您查看他们的网站并尝试一些现场示例。http://knockoutmvc.com
你很快就会爱上它。
于 2016-11-23T05:10:44.250 回答
0
MVC 是一种架构模式，它分为模型、视图和控制器三个组件。
KnockoutJS 最适合 MVC 架构，因为框架的数据绑定需要使用控制器。诸如 AngularJS 之类的框架更侧重于前端，因此它们与 MVVM 架构模式（模型、视图、视图模型）配合得更好。它们的数据绑定功能也不需要使用控制器，这减少了绑定范围。
于 2018-02-09T15:28:46.973 回答