考虑到最流行的MVC / MVVM客户端模式（如Knockout.js，Angular.js，Ember.js等），我有一个很大的疑问：
还考虑了双方的建模冗余，将这些客户端模式与MVC服务器端模式一起使用有哪些优势和劣势？
答案 0 :(得分：14)
我一直在努力解决这个问题...希望这会有所帮助，即使它是一个圆形的方式。
虽然已经说明了一些优点/缺点，但我认为最好的纲要是this answer。
对我来说，使用客户端逻辑的最大优势是丰富的UI方面。
但你问题的关键部分似乎是“模型冗余”（我称之为重复逻辑，或者至少具有重复逻辑的潜力）。在我看来，这是一个独立于前一个链接中的优点/缺点的问题。
首先，我认为是否应该使用客户端框架的决定应该基于充分记录的优缺点。做出决定后，可以解决相关问题。
让我们假设您正在使用某种服务器端框架/平台，以及客户端框架来提供一些UI交互性。现在将模型逻辑放在何处存在问题：在客户端，服务器或两者上。
解决问题的一种方法是仅在客户端或中定义模型逻辑。然后你没有代码重复，但它会影响一些更高级别的优点/缺点。
例如，如果您的模型逻辑是100％服务器端，则会丢失UI的某些交互式部分。或者，你经常将模型扔进服务器，这将有一些缺点。
如果您的模型逻辑是100％客户端，则可能会遇到性能问题，具体取决于视图/模型的大小。这是Twitter转向服务器端处理模型的原因之一。
然后有“两者”......在客户端和服务器中都存在模型逻辑。我认为这是最好的解决方案，只要没有逻辑重复。
例如，在购物车页面上，您可以根据产品价格和用户可编辑的数量框重新计算订单的成本。我认为这种逻辑应该只存在于客户端上。一旦加载就不会改变的其他模型属性可能很好地托管在服务器上。
这里有很多灰色地带......我很难把所有鸡蛋放在一个篮子里。例如，选择客户端框架，创建大量客户端逻辑，然后[假设]遇到性能，浏览器支持或类似问题。现在你可能想调整一两页的性能（比如移动服务器端，推特）。但我认为，如何构建代码是明智的，这有助于缓解这个问题。如果您的代码是可维护和清洁的，那么将逻辑从客户端移动到服务器并不困难。
答案 1 :(得分：5)
优点是客户端模式适用于服务器无法直接访问的客户端。如果您正在构建一个丰富的交互式HTML UI，那么请使用客户端MVVM。在这种情况下，服务器端MVC可能仍然与向客户端传送适当的内容相关。例如，ASP.NET WebAPI是一个用于创建HTTP API的框架，它具有与ASP.NET MVC框架类似的控制器体系结构。使用此框架实现的API可以由客户端代码调用，从而在服务器端生成MVC，在客户端生成MVVM。通常，当使用MVC服务器端和MVVM客户端时，各方的职责非常不同，因此没有冗余。
答案 2 :(得分：3)
您将MVVM模型合并到已经实现的MVC框架中的事实也是一件好事，我们最近在一些已经过时的MVC框架（旧页面，而不是框架本身）中添加了一些新的项目页面。 。
我认为MVVM很棒，因为上面的答案表明它提供了极快的响应时间的卓越用户体验，你可以在后台隐藏你的验证调用而不会降低它们的直观性。
然而痛苦的是，它非常难以进行单元测试，你可以得到一些非常大的javascript文件，还有我们不得不做的额外编码，因为我们的遗留系统仍在IE6上运行是荒谬的。
但MVVM和MVC不必单独使用，我们同时使用它们。但是有三个级别的验证仍然让我感到困扰。
答案 3 :(得分：2)
严重。利用将部分前端逻辑传输到浏览器中可以增强应用程序开发，为什么要在服务器端封装更严格的数据处理。
这基本上是分层的。两层，上面的一层与下面的一层谈话，反之亦然：
[client] <--> [server]
您通常以轻量级序列化格式（如两者之间的Json）交换值对象。
这可以很好地映射用户对有用结构的期望，而服务器端的域对象可能不那么详细。
然而，真正的力量将是如果服务器端在某些特定点没有用javascript编写，因为我认为你不能在那里创建好的域对象。如果遇到这个问题，请考虑使用Scala（或类似的表达方式）然后。
答案 4 :(得分：2)
在这个问题发布十个月之后，我在同一个应用程序中使用了这两种模式。
唯一的问题是需要两次映射模型。
MVC（ASP.NET MVC 4 Web API）
最重要的资源是路线。
MVVM（Knockout.js）
总的来说，MVC与MVVM的结合非常有用，但它需要大量的专业知识和知识。耐心也是必需的，因为你需要考虑每个应用层的责任。