是否有一个原因，我会使用Knockout MVC而不是Knockout JS？
另一个用户build议Knockout MVC来处理一些AJAX发布问题。 我读了一些，我看到它是Knockout JS的包装。 所以我想知道两者的真正区别是什么？ Knockout MVC是否存在，我应该打扰Knockout JS吗？ 我什么时候可以使用一个呢？
Knockout MVC是WebForms的混蛋 。 它通过控制器动作来路由所有viewmodel方法，这意味着发生的所有事情都必须反弹回服务器。 我不明白为什么有人会采取像knockout这样的框架，这个框架是为了客户端的MVVM，强制它为每个函数调用服务器。
此外，在服务器上执行这些方法意味着整个视图模型需要传递给服务器，并返回给客户端，为每个函数调用。 这是非常浪费的。
使用Knockout MVC意味着牺牲客户端代码的所有性能优势，以免不必编写javascript。 相同的权衡WebForms。 这不是一个好的。 这是一个反模式。
如果Knockout MVC明天去世，networking将是一个更好的地方。
我只是碰到了这个问题，有一些非常不好的反应。 我要快速增加我的两美分价值。
我刚刚开始使用KnockoutJS。 由于我正在构buildASP.NET MVC应用程序，所以使用类似Knockout MVC的东西似乎是合乎逻辑的。 在大多数情况下，这似乎是一个好主意。 我不想花时间通过我的页面写javascript和<!-- ko -->注释，如果我可以使用.Netfunction来完成我所知道和喜欢的function。
话虽如此，是的，目前KMVC有一些限制。 发送整个模型回到服务器是一个很大的。 所以我所做的就是开始我自己的knockout-mvc。 目前的变化一定是冲上去的。 但我现在有能力：
- 创build子上下文（具有完全不同的模型或视图模型的组件）
- 在调用服务器时将模型的选定部分传回
- 期望从呼叫返回不同的模型
- 围绕ajax呼叫的火灾事件
- 支持更多的html5inputtypes
- 将防伪标记传递给服务器（用于Ajax调用）
- 可能更多我忘记了
我希望很快回来，真正清理我所做的。 希望作者将这些更改包含在他的代码中。 如果没有，我想我会保持自己的叉子去。 无论哪种方式，隧道尽头都有光线。 KMVC可能需要现在的工作，但我相信这个概念绝对值得。
我绝对认为
如果Knockout MVC明天去世，networking将是一个更好的地方。
有点苛刻
编辑：
我正在查看这些意见，并再次查看原来的问题。 这样做后，我认为应该在我的答案中增加一点点：
首先，原来的问题是否有一个原因，我会使用Knockout MVC而不是Knockout JS？ 要回答/澄清（也许我只是挑剔）：Knockout MVC是一个框架，旨在使KnockoutJS与您的ASP.NET MVC应用程序集成更容易。 它主要通过使用熟悉的强types构造来生成KnockoutJS标签。 它不是KnockoutJS的替代品。 通过一切手段使用KnockoutJS。 问题是，是否也使用Knockout MVC。
话虽如此，作为开发人员的select仍然是你的select何时使用所有可用的工具的各个方面。 如果要通过向服务器执行完整请求来处理function的某个方面，请执行此操作。 如果你想执行一个Ajax请求来检索/更新数据，那就这样做。 如果你想纯粹的执行客户端function，那就这样做。
使用Knockout MVC 并不妨碍您充分利用KnockoutJS。 使用Knockout MVC 不会阻止您编写额外的JavaScript处理尽可能多的客户端function。 仅仅因为Knockout MVC提供了一个捷径来生成服务器的Ajaxcallback并不意味着你必须使用它们。 虽然，如果你的应用程序保存了数据，它将不得不在某个时候回家。
使用ASP.NET MVC构build应用程序后端是相对于仅使用Apache来提供静态HTML和脚本文件而言的。 Knockout MVC允许您继续利用这些相同的优势来协助KnockoutJS集成。
我发现Tyrsius的回答有点过于消极。 Knockout MVC还处于早期的发展阶段，但从我看得出来，它比Webforms具有一些优点，并且比Webforms更不重要。 只有在使用函数调用服务器时，Visiblity依赖才能完全在客户端上获取句柄。 当处理复杂的数据结构时，有时候需要通过服务器来完成，所以Knockout MVC可能是一个很好的方法，可以节省大量的Ajax处理工作。
这是真的，它总是来回发送整个模型，这会产生一些开销，而不是自己构build。 但我不会把它写下来。 尤其是在未来对复杂的validation进行正确的客户端处理时。
我search了一下关于淘汰赛mvc后，遇到这个职位。 虽然我同意networking带宽的浪费，但是我被这行代码所吸引：
@{ var ko = Html.CreateKnockoutContext(); }
这是一个生成击倒视图模型的整洁干净的方式。 有没有人使用淘汰的MVC只是为了这个function，而不移动所有的逻辑到服务器端？
Knockout.js的优点在于，您可以通过简单地从服务器传递JSON来传递应用程序，而无需将整个视图推送到服务器，以便生成HTML。
把它重新放在服务器上似乎是非常不直观的！ 如果你感兴趣，你最好用剃刀语法来完成你的绑定。
我的build议是使用knockout.js来进行绑定，以便绑定发生在客户端而不是服务器上，如果这是您的目标。 如果您希望您的视图在服务器上被数据绑定，请使用razor。
更多的，knockout.js肯定是非常好的客户端数据显示/删除/插入/更新，和客户端数据计算。 如果真正的商业逻辑如此简单，我们必须直接应用knockout.js。
事实是，商业逻辑并不总是那么简单。 例如，当客户端在视图上插入新的logging时，系统可能需要检查用户的authentication，根据某些业务逻辑或公式等来设置新创build的对象的默认值。无论如何，这些都应该到服务器端并检查基于数据库数据的逻辑。
开发人员能够将所有需要的业务逻辑翻译成knockout.js视图模型中的java脚本方法。 但这样，devise违反了集中处理业务逻辑的规则。
维护将成为这样的devise的噩梦。
总结，什么样的架构select真的取决于业务需求。 有时候，performance不是第一考虑。
我还可以看到很多Knockout MVC库的良好用例。 我几乎无法将KnockoutJS整合到我们的MVCnetworking应用程序中，正是因为@ChinaHelloWorld指出的原因。 这里有一些我觉得非常有用的情况。
- 强types的绑定
我喜欢强大的HTML帮助器方法，当设置KnockoutJS时，它变得完全无用和混乱。 我能做的最好的事情是手动附加我的绑定属性与辅助方法的额外参数，但我不得不再次使用魔术string。 我喜欢Knockout MVC提供的帮助器，用于创build具有强types，基于C＃expression式的绑定的input和其他元素。 不过，在这里我想提一下，我错过了生成字段的名称属性，所以我需要稍微调整一下。
- 强types的绑定语法（种类）
使用纯string绑定时，总是有拼写错误的机会，或者不完全知道要应用的绑定的正确格式。 使用Knockout MVCstream畅的API和VS IntelliSense，真正容易地应用正确的绑定。
- （几乎）自动从计算的C＃属性转换为计算的绑定
只需应用小[Computed]属性，Knockout MVC就可以用正确的KnockoutJS语法生成相应的绑定expression式。 这个也是非常有用的，我想。
- 没有viewmodel代码重复
在经典的方式中，我需要在C＃代码中使用viewmodel类，然后（几乎）在JS中使用相同的viewmodel代码（带有observable）。 那对我来说是令人沮丧的，当我看到Knockout MVC中使用的技术时，我非常高兴。 然而，我需要调整一下它能够使用真正复杂的视图模型（嵌套视图模型，集合等），并能够扩展映射Knockout视图模型，例如任何需要的自定义JS方法或计算可观察。
所以这里至less有四点非常好。 而关于视图模型往返：没有人告诉我们任何人都需要使用Knockout MVC的服务器端处理机制。 我也不会使用它，只有在服务器上需要处理一些复杂的业务逻辑的时候。 但在大多数情况下，Knockout MVC仅仅是为了简化MVC Views和KnockoutJS的绑定和设置过程。 所以我不太明白上面的不好意见。 我认为这些意见是谁写的，至less没有学习Knockout MVC的基本概念。 Yout definetely 不应该使用Knockout MVC而不是KnockoutJS，但除了KnockoutJS 。 理解JavaScript，至lessKnockoutJS的基础知识在任何情况下都是强制性的。
我希望作者继续开发Knockout MVC，因为除了这些优点以外，还有一些function和细化会使它更加强大。
在.Net MVC模式中，视图模型已经用标签“@model yourmodel”清楚地标记到每个视图/局部视图中，这可以指导开发人员理解在这个视图中会做什么。
当使用knockout.js MVVM模式时，可能看不到任何.Net视图模型，除了视图中的“data-bind”之类的标记之外。 这会使得视图和控制器解耦，难以专门为团队中的新开发人员跟踪逻辑。
我相信knockoutMVC可以解决这些困难，节省大量的javascript代码，使系统难以维护和理解。
由于knockoutMVC使得devise仍然坚持使用服务器端视图模型，因为它是C＃代码，所以易于追踪和维护。
对于一个企业项目来说，pipe理者应该总是把重点放在易于开发，易于维护，易于升级，易于理解和快速交付上来赚钱。
牺牲一点性能，但要简单一点，在客户端和服务器端的一致性应该是一个关键点。 Javascript是一个很大的维护问题。
将整个视图模型发送回服务器端是否真的是一个问题？ 如果是这样，我们可以把一个大模型分成几个小模型。
如果您没有使用由komvc生成的函数，您仍然有性能。 正如Nigel所说，最初的页面生成仍然需要由服务器生成。 您可以随时添加用户脚本并在客户端创build不需要返回到服务器的function。 这是一个给开发者一点生产力的工具。 与网页performance在性能上的比较肯定是夸张的。 伙计，这是一个工具，可以帮助你达到你的期限。
我将添加我的2分钱支持knockoutjs，虽然与knockout MVC相比，写入起来并不复杂，但是对于可重用性来说，获得的好处是巨大的。 客户端代码也可以和其他技术协调工作。
撇开安全观点，我个人觉得淘汰赛js是一种使asp.net MVC复杂化的方式，它应该像纯粹的RESTful应用程序（如asp.net webapi）一样使用（淘汰赛js）。
Knockout MVC是一个function强大的ASP .NET MVC扩展，它允许你使用开发友好的，没有Javascript的fluentAPI直接在.NET项目上实现网站客户端function，并删除大量重复和重复的代码。
淘汰赛MVC是相同的编码ASP .NET MVCrazor，你得到的客户端function没有任何额外的麻烦。
您将不必编码视图模型和绑定代码行。
我一直在我的大部分网站上使用koMVC，开发时间缩短，易于维护和最小的学习曲线是巨大的回报。
我build议你检查他们的网站，并去一些现场的例子。 http://knockoutmvc.com
它不会花很长时间让你爱上它。
