在客户端-服务器架构中使用 MVC（模型视图控制器）答案

【问题标题】：Using MVC (Model View Controller) in a Client-Server architecture在客户端-服务器架构中使用 MVC（模型视图控制器）
【发布时间】：2011-12-18 02:44:03
【问题描述】：

我正在尝试为我正在开发的应用程序选择一种设计模式。该应用程序主要基于客户端-服务器架构，其中客户端基本上读取和写入数据到服务器；然而，它不是 Web 应用程序，客户端必须安装可执行软件，然后与 GUI 交互，以便通过 Internet 协议与服务器（在不同的机器上退出）进行通信。

由于该应用程序基于与 GUI 的大量交互，我正在考虑使用 MVC 设计模式，但问题是我无法确定哪个部分应该存在于服务器端以及哪个部分应该存在于客户端。换句话说，是否可以在客户端拥有 View（即边界 GUI 类和对象）和 Controller，同时保留 Model（即实体对象）在服务器端；这是应用 MVC 模式的可行或有效方式吗？我在这里朝着正确的方向前进吗？这甚至可能吗？我的意思是那些边界和控制类可以在没有或访问同一机器或进程上的模型类的情况下运行和执行吗？

我是否应该在客户端拥有整个东西（模型、视图和控制器类），然后通过协议与服务器数据库通信？

欢迎任何建议或cmets。

【问题讨论】：

标签： design-patterns model-view-controller client

【解决方案1】：

有很多方法可以在客户端-服务器设置中实现 MVC。通常，您在客户端中放入的东西越多，您的应用程序就会变得“更丰富”或“更胖”。因此，如果您决定使用 MVC，那么真正的问题就变成了：我希望我的应用程序有多丰富？

此外，您可以让多个 MVC 实例在一个应用程序中协同工作，分布在客户端和服务器上。

我会看的一些东西：

网络：需要在客户端和服务器之间传输多少数据？一个应用程序通常会发送多少个请求？（太多可能会使网络饱和或导致其他问题）
响应性：更高的响应性可能需要您在客户端中添加更多内容
安全性：通过网络传输的所有内容都可能不太安全
性能：如果你需要高性能，你可能需要服务器上的组件
预期负载：您可能决定将更多组件放在客户端以卸载服务器，而不是集群您的后端，例如
等

【讨论】：

【解决方案2】：

您对使用 MVC 的想法是非常正确的。这将帮助您解耦事物，并使您对类有更多的控制权。

我建议将视图保留在客户端。我会将控制器和模型类保留在服务器上。控制器是棘手的组件。人们可能很容易将其保留在客户端上，将其放在服务器上的原因可能是：与 DAO 的交互、与模型类的交互、错误处理和控制流（屏幕/操作）。

客户端的控制器可能被证明很容易开发，但最终您需要将更改（如按钮按下、点击等）传递给服务器。此外，客户端的控制器将慢慢开始将您推向客户端越来越多的类。

【讨论】：

【解决方案3】：

经过大量研发后，我发现大部分控制器和客户端上的视图以及服务器上的一小部分控制器和模型的性能最佳。然后，您可以说控制器在客户端和服务器之间拆分 - 好处是，如果控制器需要已经缓存在客户端中的资产，它实际上可以避免网络流量，这对于使事情快速运行很重要。这是一个例子：http://www.youtube.com/watch?v=g73GcQqrDeA

基本上，我发现如果使用诸如服务器端模板引擎之类的东西或任何可能导致浏览器缓存未命中的东西，性能会很差，因此所有 html 必须是 100% 静态的。仅使用 jQuery，开箱即用，它提供了非常有用的事件绑定工具，您可以将其委托给也可在浏览器中缓存的控制器类。最后，唯一来回传输的数据是 JSON - 只需注意确保服务器安全，对所有重要标识符进行编码/加密，确保即使会话之间的同一用户也不相同等...

【讨论】：

【解决方案4】：

您不能真正将传统的 MVC 应用于服务器-客户端架构。原因包括：

服务器和客户端具有不同的运行时和 API。
出于安全原因，您必须在服务器上有一些业务逻辑，但除非每个用户操作都往返于服务器并返回，否则您必须有一些业务逻辑客户端也是如此（考虑表单验证）。实际上，这意味着您在两者上都有模型。
在传统 MVC 中，控制器维护对模型的引用。由于网络外观，客户端的控制器无法真正保留对服务器上模型的引用。
更重要的是，在传统的 MVC 中，模型层具有所有个模型记录。在许多 Web 应用程序中，客户端只能获得部分模型（想想第 1 页，共 3 页）。
最后两点也意味着客户端中的（部分）模型并不是真正的模型 - 如果同一模型有两个视图（想想分页的客户端列表，以及带有远程搜索的预输入下拉菜单）不同的视图）还有两个控制器 - 每个控制器都有自己的模型。因此，该模型实际上是一个幻像视图模型，而不是真实模型。

还有很多原因，但我认为以上说明了这一点。

有多种方法可以解决这个问题，获得非常接近 MVC 的东西可能涉及客户端的模型代理。到更抽象/灵活的基于命令的类代理架构。

【讨论】：

【解决方案5】：

对于灵活的架构，您可能有耦合控制器，即 cliXController 和 srvXController，一个用于客户端，一个用于服务器端。通过这种拆分，您将对各种决策点具有灵活性，例如将 View 组件放在客户端或服务器端，或者可能放在双方。您可能需要一些视图的服务器端渲染和一些视图的客户端渲染。另一方面，出于其他答案中提到的各种原因，我建议将所有模型组件放到服务器端。

【讨论】：