model-view-controller - 将客户端MVC/MVVM模式与MVC服务器端模式一起使用

Question

考虑到最流行的MVC/MVVM客户端模式(例如Knockout.js，Angular.js，Ember.js等)，我有一个很大的疑问:

另外还要考虑双方的建模冗余，将那些客户端模式与MVC服务器端模式一起使用有什么优缺点？

Answer 1

我为如何回答这个问题而苦苦挣扎...希望这会有所帮助，即使它是环回的。

虽然已经说明了一些优点/缺点，但我认为最好的减少方法是this answer。

对我来说，使用客户端逻辑的最大优势是丰富的UI方面。

但是，您问题的关键部分似乎是“模型冗余”(我称其为重复逻辑，或者至少具有重复逻辑的潜力)。我认为，这是一个可能独立于上一个链接的利弊而存在的问题。

因此，首先，我认为是否使用客户端框架的决定应基于有据可查的优缺点。一旦做出决定，相关的问题就可以解决。

假设您使用的是某种服务器端框架/平台以及客户端框架，以提供一些UI交互性。现在在哪里放置模型逻辑存在一个问题:在客户端，服务器或两者上。

解决问题的一种方法是仅在客户端或服务器中定义模型逻辑。这样就没有代码重复了，但是会影响某些高级优点/缺点。

例如，如果您的模型逻辑是100％服务器端，则您会丢失UI的某些交互部分。或者，您一直在向/从服务器抛出模型，这会有一些缺点。

如果您的模型逻辑是100％的客户端，则可能会遇到性能问题，具体取决于 View /模型的大小。这是Twitter转向服务器端处理模型的原因之一。

然后是“两者”……在客户端和服务器中都存在模型逻辑。我认为这是最好的解决方案，只要没有逻辑重复即可。

例如，在购物车页面上，您可以基于产品的价格和用户可编辑的数量框来重新计算订单成本。我认为这种逻辑应该只存在于客户端上。加载后不会更改的其他模型属性可能很好地托管在服务器上。

这里有很多灰色区域...我很难把所有的鸡蛋都放在一个篮子里。例如，选择一个客户端框架，创建许多客户端逻辑，然后[假设]遇到性能，浏览器支持等问题。现在，您可能需要调整一两个页面以提高性能(例如将其移动到服务器端，例如Twitter)。但我认为，对代码的结构方式有所了解将有助于减轻该问题。如果您的代码是可维护且干净的，那么将逻辑从客户端迁移到服务器就不会困难了。