制作 GUI 的正确方法是什么
我正在开发一系列不同的软件产品。它们已经很旧了，所以我们正在重构/改进它们。我的同事提出了抽象 GUI 并让它在自己的进程中运行并通过套接字与程序的逻辑部分进行通信的想法。这将使我们能够对所有不同的应用程序使用相同的 GUI 组件（保持相同的 LAF）。所以我的问题是：这是创建 GUI 的有效做法吗？将 GUI 与程序的其余部分联系起来会更好吗？不同方法的优缺点是什么？还有其他实现 GUI 的方法吗？
谢谢
I am working on a series of different software products. They are quite old, so we're in the process of re-factoring/improving them. My co-worker had the idea of abstracting the GUI and having it run in its own process and communicate with the logical portion of the program via sockets. This will allow us to use the same GUI components with all of the different applications (keeping the same LAF). So my question is: Is this a valid practice for creating a GUI? Would I be better off keeping the GUI tied in with the rest of the program? what are the pros and cons of the different methods, and are there any other methods for implementing GUIs?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，这是编写 GUI 程序的一种完全有效的方法。这大致就是 Web 应用程序的工作方式——UI（浏览器）通过套接字与业务逻辑服务器（Web 服务器）进行通信。
对于桌面应用程序来说，这有点不寻常，但这是可以接受的。该解决方案的优点在于，它允许您为不同平台编写多个富客户端（例如移动应用程序、Windows 应用程序、基于浏览器的应用程序等）。
您所需要做的就是定义 GUI 需要与之通信的 API后端。例如，它需要一种获取对象和保存对象的方法，以及从后端接收 UI 需要更新的通知。
Yes, it's a perfectly valid way to write a GUI program. This is roughly how web apps work -- the UI (browser) communicates to the business logic server (web server) over a socket.
It's a little bit unusual for a desktop application, but it's quite acceptable. The beauty of this solution is that it lets you write multiple rich clients for different platforms (think mobile app, windows app, browser-based app, etc.)
All you need to do is define the API that a GUI will need to talk to the back end. For example, it will need a way to get objects and save objects, and to receive notifications from the back end that the UI needs updating.
如果服务层和表示层设计得当，那就完全没问题了。总结一下我认为的优缺点：
优点：
用于多个客户端的独立 BL 服务器）。我们称之为“业务逻辑位置独立性”。
缺点：
With service and presentation layers properly designed that should be perfectly all right. To summarize pros and cons in my opinion:
Pros:
standalone BL server for several clients). Let's call is "Business logic location independence".
Cons:
取决于应用程序的类型。
桌面应用程序
如果服务器可以在专用服务器上运行，那就有意义了。如果服务器和 GUI 都安装在每个桌面上（对于大多数应用程序），这是没有意义的。然后使用不同的项目/dll 来分离 UI/业务逻辑。
网络应用程序
是的。许多 Web 应用程序都有单独的服务层，并使用 SOAP 在 GUI 和服务层之间进行通信。
套接字
如今，使用普通套接字很少是一个好的选择。当有几个优秀的 IPC 框架可用时，为什么要浪费精力/时间来构建自己的协议和实现呢？
根据评论进行更新
分而治之。将 UI 分解为尽可能小的组件，使它们可重用。将这些组件放入单独的项目/dll 中。示例组件可以是一个 UserTable，它显示所有用户的列表（采用接口
IUserService的依赖项）。不要尝试重用整个 UI 层，因为它注定会失败。原因是，如果您尝试创建一个应该可配置且通用的 UI，您最终可能会花费比使用可重用组件构建特定 UI 所需的时间更多的时间。最后，您需要添加一些小的“技巧”，对通用 UI 层进行微小的更改，以适应每个应用程序。它最终会陷入混乱。
相反，重用上述组件来为每个应用程序构建特定的 UI。
Depends on the type of application.
Desktop applications
It makes sense if the server can be run on a dedicated server. It does not make sense if both the server and the GUI are going to be installed on each desktop (for most applications). Then use different projects/dlls to separate the UI/Business logic.
Web applications
Yes. Many web applications have separate service layer an uses SOAP for communication between the GUI and the service layer.
Sockets
Using vanilla sockets is seldom a good choice today. Why waste energy/time of building your own protocol and implementation when there are several excellent IPC frameworks available.
Update in response to comment
Divide and conquer. Break down the UI into as small components as possible to make them reusable. Put those components into a separate project/dll. A sample component can be a UserTable which presents a list of all users (taking a dependency of the interface
IUserService).Don't try to reuse the entire UI layer since it's doomed to fail. The reason is that if you try to make a UI which should be configurable and generic you'll probably end up spending more time on that than what it would have taken to build a specific UI using reusable components. And in the end, you need to add small "hacks" to make minor changes to the generic UI layer to suit each application. It WILL end up in a emss.
Instead reuse the above mentioned components to build a specific UI for each application.