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

Posted 2023-02-22

【中文标题】我是不是有理由使用 Knockout MVC 而不是 Knockout JS？

【英文标题】：Is there a reason I would use Knockout MVC instead of Knockout JS?我是否有理由使用 Knockout MVC 而不是 Knockout JS？

【发布时间】：2012-07-22 00:20:22

【问题描述】：

Another user 建议Knockout MVC 处理一些 AJAX 发布问题。我读了一点，发现它是Knockout JS 的包装。所以我想知道两者之间的真正区别是什么？我应该打扰Knockout JS，因为Knockout MVC 存在吗？我什么时候会使用其中一个？

【参考方案1】：

Knockout MVC 是 WebForms 的混蛋。它通过控制器操作路由所有视图模型方法，这意味着发生的所有事情都必须反弹到服务器并返回。我不明白为什么有人会采用类似于 Knockout 的框架，它旨在成为 CLIENT SIDE MVVM，并强制它为每个功能调用服务器。

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

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

如果 Knockout MVC 明天死掉，网络将是一个更好的地方。

【讨论】：

我“假设”它的编写是为了让更精通 C# 和 ASP.NET（我也喜欢这两种很好的技术）的人们更喜欢 KO。但是，我同意我看不出使用 KO MVC 而不是 KO 的充分理由。 KO的一大亮点是富客户端和低网络聊天。

@JohnPapa 在学习 Knockout 之前，我喜欢 C# 和 ASP (MVC)。不想学习新技术和新技术在我们这个行业是一种糟糕的立场。尤其是当它导致您采用低效的技术时。如果你想开发 Web 应用程序，学习 javascript 是必须的！

我认为重要的是要记住存在利用这些行为的适当用途。例如，具有添加/编辑/保存按钮的单页应用程序需要访问服务器。在传统的帖子中，您发送表单，然后取回整个呈现的 html。使用 Knockout MVC，您只需在返回时呈现 json 而不是整个页面。 AJAX 方法需要您自己编写 JS 和 Controller 代码。所以在这种情况下，Knockout 可以为您节省重复的 JS，并且比传统的性能更好。就像任何可以使用或滥用的东西一样。

@Tyrsius，很高兴我找到了这个页面，谢谢。我被更轻松的开发体验的承诺所吸引，并正在考虑在我当前的项目中使用 KMVC，但在不了解更多信息的情况下对依赖 3rd 方库持谨慎态度。谢天谢地，我的谨慎将我带到了这个页面。您关于服务器调用破坏 Knockout 目的的观点至关重要，并且成功地阻止了我使用 KMVC（对 KMVC 开发人员表示充分尊重）。约翰爸爸同意你的事实是关键。我将使用普通的旧 KO + MVC。

Tyrsius 是完全错误的，也许你从来没有使用过 KnockOutMVC 来创建一个完整的应用程序。需要数据操作（CREATE、UPDATE、DELETE）的应用程序需要一个服务器端功能才能工作，没有这个你就活不下去。 KnockOutMVC 创建整个模型以在客户端上使用，处理与服务器的连接并创建带有绑定的视图以供客户端使用。所有客户端逻辑都保留在客户端中，不需要服务器，也许你错过了正确使用它的解释。

【参考方案2】：

我刚刚遇到了这个问题，它有一些非常消极的回答。我将迅速增加我的两美分的价值。

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

话虽如此...是的，目前 KMVC 存在一些限制。将整个模型发送回服务器是一件大事。所以我所做的是开始了我自己的knockout-mvc 分支。目前，这些变化必然是仓促的。但我现在有能力：

创建子上下文（具有完全不同的模型或视图模型的组件） 调用服务器时将模型的选定部分传回 预计呼叫返回的模型与发送的模型不同 围绕 ajax 调用触发事件 支持更多的 html5 输入类型 通过标头将防伪令牌传递给服务器（用于 ajax 调用） 我可能忘记了更多

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

我绝对认为

如果 Knockout MVC 明天死掉，网络将是一个更好的地方。

有点苛刻。

编辑：

我在查看 cmets 并再次查看原始问题是什么。完成后，我认为应该在我的答案中添加更多内容：

首先，最初的问题是 我是否有理由使用 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 集成。

【讨论】：

我认为I don't want to be spending time writing javascript既是KMVC存在的原因，也是它最大的缺陷。当您尝试避免使用 javascript 时，您正在与网络作斗争。

@Tyrsius，我不同意你的观点。我不是想避免使用 javascript。当我可以使用工具为我做这件事时，我避免了手动编写 javascript。这与我首先使用 KnockoutJS 的原因相同。我可以自己编写那个功能，但是为什么当它都被包含在一个对我来说很好的工具集中时。同样，当我可以让 KMVC 为我做这件事时，为什么还要在我的文件中手动编写 javascript（至少是基本位）？结果页面应该没有区别，只是在开发工作中。

除了结果页面有所不同，您的回答解决了这个问题：KMVC 要求服务器执行任何操作。常规的 KnockoutJs 应用程序不会。这不仅仅是开发工作的差异，也是性能的差异。

我认为您假设的是最坏的情况。如果使用得当，KMVC 应该是一个辅助生成 Knockout 绑定等的工具。性能优势仍然存在。 Web 应用程序当然仍然依赖于服务器来至少执行初始页面生成......就像任何基于 Web 的应用程序一样。

除非他们不在那里。一旦视图模型函数进入服务器执行其逻辑，就像任何视图模型函数或computed observable 在 KMVC 中所做的那样，性能优势已经丧失。 Knockout 会在客户端完成，KMVC 需要服务器请求。没有办法绕过它：KMVC 用性能和响应能力换取不写 javascript。

【参考方案3】：

我觉得 Tyrsius 的回答有点过于否定。 Knockout MVC 仍处于早期开发阶段，但据我所知，它具有一些优势，并且比 Webforms 的服务器负担更轻。可见性依赖完全在客户端获得句柄，只有在使用函数时才会调用服务器。在处理复杂的数据结构时，有时无论如何都需要通过服务器，因此 Knockout MVC 可能是节省自己编写大量 Ajax 处理的好方法。

确实，它总是来回发送整个模型，这会产生一些开销，而不是自己构建它。但我不会完全注销它。尤其是当它在未来为复杂的验证得到适当的客户端处理时。

【讨论】：

那么关于这个框架，你能说的最好的一点就是它在未来会变得更好？

【参考方案4】：

在搜索了一些关于淘汰赛 mvc 的信息后，我发现了这篇文章。虽然我同意浪费网络带宽，但我还是被那行代码迷住了：

@
  var ko = Html.CreateKnockoutContext();
 

这是生成淘汰视图模型的一种简洁明了的方法。有没有人使用淘汰赛 MVC 只是为了该功能而不将所有逻辑移动到服务器端？

【讨论】：

我很想看到对此的回应，因为我发现自己重复了很多我已经在服务器端编写的代码客户端。

@Sam 我找到了一种不用 KnockoutMVC 的方法。只需使用敲除映射：var myViewModel = ko.mapping.fromJS([Return MVC model as JSON]);。无需 AJAX 即可工作。

我已经停止使用 AngularJS 的淘汰赛，但感谢分享这个:)

【参考方案5】：

Knockout.js 的美妙之处在于，您可以通过简单地从服务器来回传递 JSON 来为您的应用程序提供服务，而无需推送整个视图，服务器必须将整个视图分块以生成 HTML。

再次将其放回服务器似乎非常违反直觉！如果您对此感兴趣，最好首先使用剃刀语法来完成绑定。

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

【讨论】：

+1 也是如此。带有剃刀服务器端的客户端上的组合 og 淘汰赛对我来说似乎是“明智的”方式。 tyrsius 的好句子，引起了任何需要处理网络表单的人的共鸣！！

@jimtollan 似乎使用 KO-JS 您必须编写两次 ViewModel。一次在客户端，另一次在服务器上。这似乎不太明智。 KO-MVC 似乎解决了这个问题。但是，我没有意识到它带来了一大堆问题。

@dotnetN00b，这是真的。在某些情况下，淘汰映射插件可以解决这个问题，但在其他情况下，您可能需要编写两次视图模型。问题是，你的 c# 视图模型不应该有相同的功能，只是他的道具。任何客户端操作都将在您的 KO 视图模型中，任何服务器操作（如果有）将在 c# 中。作为交换，您可以保持快速、高性能的客户端视图和一致的数据。

@dotnetN00b，并非总是如此。我发现在大多数情况下，ViewModel 只在 js 中定义，因为控制器操作只会发送基于域模型的 JSON，而不是单独的视图模型。

@OnResolve 您如何获取视图的初始数据？如果它们比直接的数据库记录模型更复杂，它们可能会得到一个服务器端视图模型。

【参考方案6】：

此外，knockout.js 确实非常擅长客户端数据显示/删除/插入/更新，以及客户端数据计算。如果一个真正的业务逻辑这么简单，我们必须直接应用knockout.js。

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

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

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

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

【参考方案7】：

我还可以看到很多使用 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，因为除了这些优点之外，还有一些功能和改进确实会让它变得更加强大。

【讨论】：

关于第 4 点：如果您在客户端有良好的映射/合并技术，则不需要复制您的视图模型，所以，这里我只有模型上的属性，我没有需要在服务器上设置，这样我就不需要两边都创建了。

@DavidFreire 在不太复杂的应用程序中确实如此，但是在构建一个非常复杂的应用程序时，最终我总是希望我声明了那些可观察的。例如，如果我想创建一个基于其他一些可观察对象的计算，那么我必须声明它们，不能动态映射它们。实际上，我在过去的一年中放弃了 Knockout MVC 并使用我自己的服务器端助手，并且我创建了一个“工具”来将我的 C# 模型转换为 TypeScript。这种技术一起工作真的很棒。如果有时间，我会在某个地方发布此工具。

你是完全正确的，如果你在你的视图上使用计算的 observables 是一个问题，但对于更简单的情况它可以工作。

@ZoltánTamási 你有没有发布过你提到的那个工具？

@kayess 如果您指的是 C# 到 TS 的“转换器”，我还没有发布它，虽然我仍然想发布它，但不幸的是我不打算发布它，因为它会有点工作，这些年来我的空闲时间真的很有限。我将它用作我们内部框架的一部分。不过，互联网上有几个类似的选项。

【参考方案8】：

在.Net MVC模式中，视图模型已经清楚地标记到每个视图/部分视图中，带有标签“@model yourmodel”，可以指导开发人员了解该视图将做什么。

使用 knockout.js MVVM 模式时，您可能不会看到任何 .Net 视图模型，除了视图中的“data-bind”等标签。这将使视图和控制器解耦，并且难以专门为团队中的新开发人员跟踪逻辑。

我相信knockoutMVC可以解决这些困难，节省大量的javascript代码，使系统难以维护和理解。

由于knockoutMVC使得设计仍然坚持应用服务器端视图模型，因为它是C#代码，因此易于跟踪和维护。

对于一个商业项目，经理应该始终专注于易于开发、易于维护、易于升级、易于理解和快速交付以赚钱。

牺牲一点性能但让它变得简单，客户端和服务器端的一致性应该是一个关键点。 Javascript 是一个很大的维护问题。

将整个视图模型发送回服务器端真的很重要吗？如果是这样，我们可以将一个大模型拆分为几个小模型。

【讨论】：

基于非常痛苦的经历，非常出色并且完全同意

【参考方案9】：

如果你不使用 komvc 生成的函数，你仍然有性能。正如 Nigel 所说，初始页面生成仍然必须由服务器生成。您始终可以在客户端添加用户脚本并创建不需要返回服务器的功能。它是一种工具，可以为开发人员提供一点生产力。与 Web 表单在性能上的比较肯定被夸大了。伙计们，这是一个可以帮助您按时完成任务的工具。

【参考方案10】：

我将增加我的 2 美分来支持 knockoutjs，尽管与淘汰赛 MVC 相比编写起来有点复杂，但在可重用性方面你获得的好处是巨大的。客户端代码也可以与其他技术和谐地工作。

撇开安全角度不谈，我个人认为淘汰 js 是使 asp.net MVC 复杂化的一种方式，它应该按原样（淘汰 js）与纯 RESTful 应用程序（如 asp.net webapi）一起使用。

【讨论】：

什么安全角度？

如果您使用客户端来管理隐藏/显示的内容以及通常在淘汰赛示例中完成的其他功能，您通常需要向客户端发送更多信息。

在我的上下文中的安全视角，例如：***.com/questions/19375173/mvc-4-web-api-security

【参考方案11】：

Knockout MVC 是 ASP .NET MVC 的一个强大扩展，它允许您使用开发人员友好的 fluentAPI 直接在您的 .NET 项目上实现网站客户端功能，无需 Javascript 并删除大量重复和重复的代码。 淘汰 MVC 与编写 ASP .NET MVC 剃须刀相同，您可以轻松获得客户端功能。 您不必编写视图模型和绑定代码行。 我一直在我的大多数网站上使用 koMVC，开发时间减少、易于维护和最小的学习曲线是一个巨大的回报。 我建议您查看他们的网站并尝试一些现场示例。 http://knockoutmvc.com 很快你就会爱上它。

【讨论】：

同意。同时，作为淘汰赛的包装（不是替代品），您可以根据需要使用它。我希望它仍在开发中以支持最新版本的淘汰赛。

【参考方案12】：

MVC 是一种架构模式，分为模型、视图和控制器三个组件。

KnockoutJS 最适合 MVC 架构，因为框架的数据绑定需要使用控制器。诸如 AngularJS 之类的框架更侧重于前端，因此它们与 MVVM 架构模式（模型、视图、视图模型）配合得更好。它们的数据绑定功能也不需要使用控制器，这减少了绑定范围。