在客户端-服务器架构中使用 MVC（模型视图控制器）
我正在尝试为我正在开发的应用程序选择一种设计模式。该应用程序主要基于客户端-服务器架构，其中客户端基本上向服务器读取和写入数据；然而，它不是一个 Web 应用程序，客户端必须安装可执行软件，然后与 GUI 交互，以便通过互联网协议与服务器（存在于另一台机器上）进行通信。
由于该应用程序基于与 GUI 的大量交互，因此我正在考虑使用 MVC 设计模式，但问题是我无法决定哪个部分应该存在于服务器端，哪个部分应该存在于客户端。换句话说，是否可以将视图（即边界GUI 类和对象）和控制器放在客户端，同时保留模型< /strong>（即实体对象）在服务器端；这是应用 MVC 模式的可行或有效的方法吗？我在这里的方向正确吗？ 这可能吗？我的意思是，这些边界和控制类可以在没有或访问同一机器或进程上的模型类的情况下操作和执行吗？
我应该在客户端拥有整个东西（模型、视图和控制器类），然后通过协议与服务器数据库进行通信吗？
欢迎任何建议或意见。
I'm trying to choose an design pattern for an application that I'm developing. The application is primarily based on a Client-Server architecture where the Client basically reads and writes data to the Server; its not a Web-application however, The client will have to install the software executable and then interact with a GUI in order to communicate with the Server (which exits on a different machine) through an internet protocol.
Since the application is based on heavy interaction with a GUI, I was thinking about using the MVC design pattern, the thing is I'm having trouble deciding which part should exist on the Server and which on the Client side. In other words, is it ok to have the View (i.e the Boundary GUI classes and objects) and the Controller on the Client side, while leaving the Model (i.e the Entity objects) on the Server side; is this a viable or valid way of applying the MVC pattern ? Am I going in the right direction here ?
Is this even possible ? I mean can those Boundary and Control classes operate and execute without having or accessing the Model classes on the same machine or process ?
Should I have the whole thing (The Model, View and Controller classes) on the Client side and then just communicate with the Server database via the protocol ?
Any suggestions or comments would be welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在客户端-服务器设置中实现 MVC 的方法有很多种。一般来说，您在客户端中放入的内容越多，您的应用程序就会变得“更丰富”或“更胖”。因此，如果您决定使用 MVC，那么您真正的问题就变成：我希望我的应用程序有多丰富？
此外，您可以在一个应用程序中让多个 MVC 实例一起工作，分布在客户端和服务器上。
我会关注的一些事情：
网络：需要在客户端和服务器之间传输多少数据？应用程序通常会发送多少个请求？ （太多可能会使网络饱和或引起其他麻烦）
响应能力：更高的响应能力可能要求您在客户端投入更多
：通过网络传输的所有内容都可能不太安全
性能：如果您需要高性能，则可能需要服务器上的组件
预期负载：您可能决定在客户端放置更多组件以减轻服务器负担，而不是例如对后端进行集群
等
There are a lot of ways of implementing MVC in a client-server setting. In general, the more stuff you put in the client the "richer" or "fatter" your application becomes. So, if you decide on using MVC, the real question for you then becomes: how rich do I want my application to be?
Also, you can have multiple instances of MVC working together in one application, distributed over client and server.
Some of the things I would look at:
network: How much data needs to be shuttled between client and server? How many requests will an application typically send? (too much may saturate the network or cause other trouble)
responsiveness: higher responsiveness can require you to put more in the client
security: everything that goes over the wire may be less secure
performance: if you need high performance, you may need components on the server
expected loads: you may decide to put more components client-side to offload the server, instead of clustering your backend for example
etc.
您无法真正将传统的 MVC 应用于服务器-客户端架构。原因包括：
原因还有很多，但我认为以上已经说明了这一点。
有多种方法可以解决这个问题，获得非常接近 MVC 的东西可以涉及客户端的模型代理。到更抽象/灵活的基于命令的代理式架构。
You can't really apply traditional MVC to server-client architecture. Reasons include:
There're many more reasons, but I think the above demonstrates the point.
There are various ways to combat this, getting something very close to MVC can involve a model proxy on the client side. To the more abstract/flexible command based agent-like architecture.
您关于使用 MVC 的想法是非常正确的。这将帮助您解耦事物并让您更好地控制类。
我建议将视图保留在客户端。我会将控制器和模型类保留在服务器上。控制器是比较棘手的组件。人们可能很容易想将其保留在客户端，将其放在服务器上的原因是：与 DAO 交互、与模型类交互、错误处理和控制流（屏幕/操作）。
客户端的控制器可能被证明很容易开发，但最终您需要将更改（如按钮按下、单击等）传递到服务器。此外，客户端的控制器会慢慢地开始将你推向客户端越来越多的类。
Your thoughts about using MVC is quite right. This will help you de-couple things and will give you more control on classes.
I would suggest keeping the view on the client side. I would keep the controller and model classes on the server. Controller is the component that's tricky. One may be easily tempted to keep it on the client, reasons to put it on the server would be: interactions with DAOs, interactions with Model classes, error handling and control flow (of screens/actions).
A controller on the client side may prove to be easy to develop but ultimately you need to pass changes (like button presses, clicks etc etc) to the server. Further, a controller on the client side would then slowly start pushing you towards more and more classes on the client side.
经过大量的研发，发现大部分控制器和客户端上的视图以及服务器上的一小部分控制器和模型具有最佳性能。然后，您可以说控制器跨客户端和服务器分开 - 好处是，如果控制器需要已缓存在客户端中的资产，它实际上避免了网络流量，这对于使事情快速运行非常重要。以下是一个示例：http://www.youtube.com/watch?v=g73GcQqrDeA
基本上，我发现如果使用服务器端模板引擎或任何可能导致浏览器缓存未命中的东西，性能会很差，因此所有 html 必须是 100% 静态的。仅使用 jQuery，开箱即用，它提供了非常有用的事件绑定工具，您可以将其委托给也可在浏览器中缓存的控制器类。最后，唯一来回传输的数据是 JSON - 只需注意确保服务器安全，对所有重要标识符进行编码/加密，确保即使是同一用户在会话之间它们也不相同......
After a lot of R&D I found best performance with the majority of the controller and the view on the client, and also a small part of controller and model on the server. You could then say the controller was split across client and server - the benefit being that if the controller needs assets that are already cached in the client, it actually avoids network traffic which is important in making things run fast. Here is an example: http://www.youtube.com/watch?v=g73GcQqrDeA
Basically I found that performance was bad if using such things as server-side template engines or anything that can for a cache miss from the browser, so all html must be 100% static. Using jQuery only, out of the box it provides really useful event binding facilities that you can delegate to a Controller Class that is also cacheable at the browser. In the end, the only data going back and forth is JSON - just take care in making your server secure, encode/encrypt all important identifiers, make sure they aren't the same for even the same user between sessions etc...
为了实现灵活的架构，您可能拥有耦合控制器，即 cliXController 和 srvXController，一个用于客户端，一个用于服务器端。通过这种拆分，您将对各种决策点具有灵活性，例如将视图组件放置在客户端或服务器端，或者可能放置在两侧。您可能需要对某些视图进行服务器端渲染，对某些视图进行客户端渲染。另一方面，出于其他答案中提到的各种原因，我建议将所有模型组件放在服务器端。
For a flexible architecture you may have coupled controllers, i.e., cliXController and srvXController, one for the client side and one for the server side. With this splitting, you will have a flexibility for various decision points, such as putting View component to client or server side, or maybe to the both sides. You may want server side rendering for some of the views and client side rendering for some of the views. On the other hand, I would suggest to put all the Model component to server side for various reasons mentioned in other answers.