Design patterns 在客户机-服务器体系结构中使用MVC（模型-视图-控制器）

我试图为我正在开发的应用程序选择一种设计模式。该应用程序主要基于客户机-服务器体系结构，其中客户机基本上向服务器读取和写入数据；但是，它不是一个Web应用程序，客户端必须安装软件可执行文件，然后与GUI交互，以便通过internet协议与服务器（存在于另一台机器上）通信

由于该应用程序基于与GUI的大量交互，所以我考虑使用MVC设计模式，问题是我很难确定服务器上应该存在哪个部分，客户端应该存在哪个部分。换句话说，在客户端有视图（即边界GUI类和对象）和控制器（即服务器端有模型（即实体对象）可以吗；这是应用MVC模式的可行或有效的方法吗？我走的方向对吗？ 这可能吗？我的意思是，这些边界类和控制类是否可以在同一台机器或进程上不拥有或访问模型类的情况下运行和执行

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

---

欢迎您提出任何建议或意见。

您关于使用MVC的想法非常正确。这将帮助您消除耦合，并使您能够更好地控制类

我建议将观点放在客户方。我将在服务器上保留控制器和模型类。控制器是一个复杂的组件。人们可能很容易将其保留在客户机上，将其放在服务器上的原因是：与DAO的交互、与模型类的交互、错误处理和控制流（屏幕/操作）

---

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

在客户机-服务器设置中有很多实现MVC的方法。一般来说，在客户机中输入的内容越多，应用程序就越“丰富”或“肥胖”。因此，如果您决定使用MVC，那么真正的问题是：我希望我的应用程序有多丰富

此外，您可以在一个应用程序中使用多个MVC实例，这些实例分布在客户机和服务器上

我会看一些东西：

• 网络：客户端和服务器之间需要穿梭多少数据？一个应用程序通常会发送多少个请求？（过多可能会使网络饱和或导致其他故障）

• 响应性：更高的响应性可能要求您在客户端投入更多

• 安全：所有通过电线的东西都可能不那么安全

• 性能：如果需要高性能，可能需要服务器上的组件

• 预期负载：例如，您可能决定在客户端放置更多组件以卸载服务器，而不是对后端进行集群

• 等等

---

经过大量的研发，我发现客户机上的大部分控制器和视图以及服务器上的一小部分控制器和模型性能最佳。然后，您可以说控制器在客户机和服务器之间进行了拆分—好处是，如果控制器需要已经缓存在客户机中的资产，它实际上可以避免网络流量，这对于快速运行非常重要。以下是一个例子：

---

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

您无法将传统的MVC应用于服务器-客户端体系结构。原因包括:

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

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

有各种各样的方法来解决这个问题，非常接近MVC可能需要在客户端使用一个模型代理。到更抽象/灵活的基于命令的代理式体系结构。