Another user建议Knockout MVC处理一些AJAX发布问题。我读了一下，我发现它是Knockout JS的包装。所以我想知道两者之间真正的区别是什么？自Knockout JS存在以来，我是否应该为Knockout MVC而烦恼？我何时才能使用其中一个？
答案 0 :(得分：124)
Knockout MVC是WebForms的私生子。它通过控制器操作路由所有viewmodel方法，这意味着发生的一切都必须反弹到服务器并返回。我无法理解为什么有人会采用像淘汰赛一样的框架，这是一个客户端MVVM，并强制它为每个功能调用服务器。
此外，在服务器上执行这些方法意味着需要将整个viewmodel 传递给服务器，并返回到客户端，以进行每个函数调用。 这非常浪费。
使用Knockout MVC意味着牺牲客户端代码的所有性能优势，以便不必编写javascript。 WebForms做出了同样的权衡。这不是一个好的。这是一个反模式。
如果Knockout MVC明天去世，那么网络将是一个更好的地方。
答案 1 :(得分：21)
我刚遇到这个问题，其中有一些非常消极的回答。我要快速加上我的两分钱。
我刚刚开始使用KnockoutJS。由于我正在构建ASP.NET MVC应用程序，因此使用Knockout MVC这样的东西似乎合乎逻辑。在大多数情况下，这似乎是个好主意。我不想花时间在我的网页上写javascript和<!-- ko -->评论，如果我可以使用我熟悉和喜爱的.Net功能来做同样的事情。
话虽如此......是的，目前KMVC存在局限性。将整个模型发送回服务器是一个很大的问题。所以我所做的就是开始自己的淘汰赛 - mvc。这些变化此刻一定是匆忙的。但我现在有能力：
我希望尽快回来并真正清理我所做的事情。希望作者将这些更改包含在他的代码中。如果没有，我想我会保持自己的叉子。无论哪种方式，隧道尽头都有光。 KMVC可能需要现在的工作，但我相信这个概念绝对值得做。
我绝对认为
如果Knockout MVC明天去世，那么网络将是一个更好的地方。
有点苛刻。
修改
我正在查看评论，并再次查看原始问题是什么。完成后我想我应该再添加一点：
首先，原来的问题是我是否有理由使用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集成。
答案 2 :(得分：13)
我发现Tyrsius的回答有点过于消极。淘汰赛MVC仍处于早期开发阶段，但从我所看到的它有一些优势，并且比Webforms的服务器更重要。 Visiblity dependancies完全在客户端上获取句柄，只有在使用函数时才对服务器进行调用。在处理复杂的数据结构时，有时需要通过服务器，因此Knockout MVC可能是节省自己编写大量Ajax处理的好方法。
确实它总是来回发送整个模型，这会产生一些开销而不是自己构建它。但我不会完全把它写下来。特别是当它在将来对复杂的验证进行适当的客户端处理时。
答案 3 :(得分：11)
我在搜索了一些关于淘汰mvc之后发现了这篇文章。虽然我同意浪费网络带宽，但我对这段代码非常感兴趣：
@{
var ko = Html.CreateKnockoutContext();
}
这是一种用于生成挖空视图模型的简洁方法。有没有人使用淘汰MVC只为该功能而没有将所有逻辑移动到服务器端？
答案 4 :(得分：8)
Knockout.js的优点在于，您可以通过简单地从服务器来回传递JSON来获得您的应用程序，而无需推送服务器必须大量生成HTML的整个视图。
将它重新放回服务器似乎非常违反直觉！如果您感兴趣，最好先使用剃刀语法来完成绑定。
我的建议是使用knockout.js来进行绑定，以便绑定发生在客户端而不是服务器上，如果这是你想要的目标。如果您希望视图是服务器上的数据绑定，请使用razor。
答案 5 :(得分：6)
更多，knockout.js肯定非常擅长客户端数据显示/删除/插入/更新以及客户端数据计算。如果真正的业务逻辑就像那样简单，我们必须直接应用knockout.js。
事实是，商业逻辑并不总是那么简单。例如，当客户端在视图上插入新记录时，系统可能需要检查用户的身份验证，根据某些业务逻辑或公式等设置新创建对象的默认值...所有这些，无论如何，应该去服务器端并检查基于数据库数据的逻辑。
Developer能够将所有必需的业务逻辑转换为knockout.js视图模型中的java脚本方法。但是这样，设计违反了集中处理业务逻辑的规则。
维护将成为此类设计的噩梦。
总结，什么框架选择真正取决于业务需求。有时，性能不是首要考虑因素。
答案 6 :(得分：6)
我还可以看到许多使用Knockout MVC库的好用例。我很难将KnockoutJS集成到我们的MVC网络应用程序中，正是因为@ChinaHelloWorld所指出的原因。以下是我发现它非常有用的一些情况。
我喜欢好的强类型HTML帮助程序方法，在设置KnockoutJS时变得完全无用且混乱。我能做的最好的事情是使用辅助方法的额外参数手动附加我的绑定属性，但我不得不再次使用魔术字符串。我喜欢Knockout MVC提供的帮助程序，用于使用强类型，基于C＃表达式的绑定创建输入和其他元素。但是，在这里我想提一下，我想念生成字段的name属性，所以我需要稍微调整一下。
使用纯字符串绑定时，总是很有可能拼写错误，或者不完全知道您要应用的绑定的正确格式。使用Knockout MVC和VS IntelliSense的流畅API，可以很容易地应用正确的绑定。
只需应用小的[Computed]属性，Knockout MVC就可以用正确的KnockoutJS语法生成相应的绑定表达式。我认为这个非常有用。
以经典的方式，我需要在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，因为除了这些优点之外，还有一些功能和改进可以使它更加强大。
答案 7 :(得分：4)
在.Net MVC模式中，视图模型已经使用标记“@model yourmodel”清楚地标记到每个视图/部分视图中，这可以指导开发人员了解在此视图中将执行的操作。
当使用knockout.js MVVM模式时，你可能看不到任何.Net视图模型，除了视图中的“data-bind”之类的标签。这会使视图和控制器脱钩，并且难以专门为团队中的新开发人员跟踪逻辑。
我相信knockoutMVC可以解决这些困难并节省大量的javascript代码，这将使系统难以维护和理解。
由于knockoutMVC使设计仍然坚持使用易于跟踪和维护的服务器端视图模型，因为它是C＃代码。
对于一个商业项目，经理应该始终专注于易于开发，易于维护，易于升级和易于理解，并快速交付以赚钱。
牺牲一点性能，但要简单，客户端和服务器端的一致性应该是关键点。 Javascript是一个很大的维护问题。
将整个视图模型发送回服务器端真的很重要吗？如果是这样，我们可以将一个大型模型拆分为几个小模型。
答案 8 :(得分：2)
如果你没有使用komvc生成的函数，你仍然有性能。正如奈杰尔所说，初始页面生成仍然必须是服务器生成的。您始终可以在客户端添加用户脚本和创建不需要返回服务器的功能。它是一种为开发人员提供一点生产力的工具。与Web表单在性能上的比较肯定是夸大其词。伙计们，这是一个确保帮助您满足截止日期的工具。
答案 9 :(得分：1)
我将加入我的2美分赞成knockoutjs，虽然与淘汰MVC相比，写起来并不复杂，但在重新使用时，你获得的好处是巨大的。客户端代码也可以与其他技术协调工作。
撇开安全角度我个人认为淘汰js是一种使asp.net MVC复杂化的方式，它应该与原始的RESTful应用程序（如asp.net webapi）一起使用（knockout js）。
答案 10 :(得分：1)
Knockout MVC是ASP .NET MVC的强大扩展，它允许您使用开发人员友好的fluentAPI直接在.NET项目上实现网站客户端功能，而无需使用Javascript并删除大量重复和重复的代码。
淘汰MVC与编写ASP .NET MVC剃刀相同，您可以毫不费力地获得客户端功能。
您不必编写视图模型和绑定代码行
我一直在我的大多数网站上使用koMVC，开发时间减少，易于维护和最小化学习曲线是一个巨大的回报。
我建议你查看他们的网站，并参加一些实例。 http://knockoutmvc.com
你不必花很长时间就爱上它。
答案 11 :(得分：0)
MVC是一种架构模式，它分为三个组件，模型，视图和控制器。
KnockoutJS最适合MVC架构，因为框架的数据绑定需要使用控制器。有一些框架，例如AngularJS，它更多地关注前端，因此它们更适合MVVM架构模式（模型，视图，视图模型）。它们的数据绑定功能也不需要使用控制器来减少绑定范围。