将客户端 MVC/MVVM 模式与 MVC 服务器端模式结合使用

Posted 2023-02-24

技术标签:

【中文标题】将客户端 MVC/MVVM 模式与 MVC 服务器端模式结合使用【英文标题】：Use client-side MVC/MVVM patterns with MVC server-side pattern 【发布时间】：2012-07-30 15:46:55 【问题描述】：

考虑到最流行的 MVC/MVVM 客户端模式（如 Knockout.js、Angular.js、Ember.js 等），我有一个很大的疑问：

同样考虑到双方的建模冗余，将这些客户端模式与 MVC 服务器端模式一起使用有什么优点和缺点？

【问题讨论】：

【参考方案1】：

优点是客户端模式适用于服务器无法直接访问的客户端。如果您正在构建丰富的交互式 html UI，请使用客户端 MVVM。在这种情况下，服务器端 MVC 可能仍然与向客户端提供适当的内容相关。例如，ASP.NET WebAPI 是一个用于创建 HTTP API 的框架，它具有与 ASP.NET MVC 框架类似的控制器架构。使用此框架实现的 API 可以由客户端代码调用，从而在服务器端产生 MVC，在客户端产生 MVVM。通常，在使用MVC服务器端和MVVM客户端时，各自的职责是非常不同的，因此没有冗余。

【讨论】：

【参考方案2】：

您将 MVVM 模型合并到已经实现的 MVC 框架中也是一件好事，我们最近在一些新项目页面中添加了淘汰赛以适应已经过时的 MVC 框架（旧页面，而不是框架本身） .

我认为 MVVM 非常棒，因为上述答案表明它提供了卓越的用户体验和极快的响应时间，您可以在后台隐藏验证调用而不会减慢它们的速度，而且它很直观。

然而，痛苦在于单元测试非常困难，而且您可以获得一些非常大的 javascript 文件，而且由于我们的遗留系统仍然在 IE6 上运行，我们不得不做的额外编码是荒谬的。

但 MVVM 和 MVC 不必单独使用，我们两者都使用。但是有 3 个级别的验证仍然让我感到困扰。

【讨论】：

我注意到您的第二次表扬，您已经在考虑在项目中同时使用这两种方法，抱歉！感谢您的回答，在我的项目研究中会非常考虑。很快我会选择最佳答案。再次感谢！在您的第二段中，您似乎暗示使用 MVVM 与客户端模式相同。事实并非如此。 MVVM 可用于服务器端或客户端。【参考方案3】：

我为如何回答这个问题而苦恼……希望这会有所帮助，即使它是以迂回的方式。

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

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

但是您问题的关键部分似乎是“模型冗余”（我将其称为重复逻辑，或者至少具有重复逻辑的潜力）。在我看来，这是一个可能独立于上一个链接中的优缺点而存在的问题。

所以首先，我认为是否使用客户端框架的决定应该基于有据可查的利弊。一旦做出决定，相关的问题就可以得到解决。

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

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

例如，如果您的模型逻辑 100% 是服务器端的，那么您会丢失一些 UI 的交互部分。或者，您不断地向服务器发送模型或从服务器发送模型，这会有一些缺点。

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

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

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

这里有很多灰色区域......我很难将所有鸡蛋放在一个篮子里。例如，选择客户端框架，创建大量客户端逻辑，然后 [假设地] 遇到性能、浏览器支持或类似问题。现在您可能想要调整一两个页面以提高性能（例如将其移动到服务器端，例如 Twitter）。但我认为明智地构建代码将有助于缓解这个问题。如果您的代码是可维护且干净的，那么将逻辑从客户端移动到服务器不会很困难。

【讨论】：

“只要没有逻辑重复”这句话回答了所有问题。【参考方案4】： 优势这可以摇滚。缺点你可以搞砸了。

说真的。利用将部分前端逻辑传输到浏览器中可以促进您的应用程序开发，为什么您将更严格的数据处理封装在服务器端。

这基本上是分层的。两层，上一层与下一层对话，反之亦然：