制作GUI的正确方法是什么？

Question

我正在研究一系列不同的软件产品。它们已经很老了，所以我们正在重新分解/改进它们。我的同事有想法抽象GUI并让它在自己的进程中运行，并通过套接字与程序的逻辑部分进行通信。这将允许我们在所有不同的应用程序中使用相同的GUI组件（保持相同的LAF）。所以我的问题是：这是创建GUI的有效做法吗？我是否会更好地保持GUI与程序的其余部分相关联？不同方法的优点和缺点是什么，还有其他实现GUI的方法吗？

由于

Answer 1

是的，这是编写GUI程序的一种非常有效的方法。这大致是Web应用程序的工作方式 - UI（浏览器）通过套接字与业务逻辑服务器（Web服务器）进行通信。

桌面应用程序有点不寻常，但它是完全可以接受的。这个解决方案的优点在于它可以让您为不同的平台编写多个富客户端（想想移动应用程序，Windows应用程序，基于浏览器的应用程序等）。

您需要做的就是定义GUI与后端通信所需的API。例如，它需要一种方法来获取对象并保存对象，并从后端接收UI需要更新的通知。

Answer 2

正确设计的服务和表示层应完全正确。总结一下我认为的优点和缺点：

优点：

1. UI没有物理绑定到逻辑，因此逻辑层可以是远程的（甚至是 几个客户端的独立BL服务器）。我们称之为“业务逻辑位置独立性”。
2. 可以创建不同版本的GUI（而不仅仅是图形 - 可以将BL作为服务公开，例如作为提要或报告端点），“GUI平台独立性”以及SOA方法。
3. 在BL和GUI之间添加代理的可能性 - 用于安全性和缓存目的。或者在应用程序场前面加载均衡器。或者在重大BL更改后支持“旧”客户端的适配器。 （“弹性和失效安全”？）
4. 在某种程度上部署可能更容易（修复UI中的错误不会影响BL层 - 只是二进制模块独立性的结果）
5. 能够向GUI添加“离线模式”。

缺点：

1. 您正在添加一个连接链接，这可能是另一个失败点，并且应该花一些时间来测试它。
2. 增加GUI和BL之间的数据流量，可能还有更多的序列化工作。
3. 需要跟踪通信协议更改和正确的协议版本维护。
4. （代理能力的负面）GUI和BL之间的中间人攻击的可能性。

Answer 3

取决于申请类型。

桌面应用

如果服务器可以在专用服务器上运行，这是有意义的。如果要在每个桌面上安装服务器和GUI（对于大多数应用程序），则没有意义。然后使用不同的项目/ dll来分离UI / Business逻辑。

网络应用

是。许多Web应用程序具有单独的服务层，并使用SOAP进行GUI与服务层之间的通信。

<强>套接字

今天使用香草插座很少是一个不错的选择。当有几个优秀的IPC框架可用时，为什么要浪费能源/时间来构建自己的协议和实现。

更新以回复评论

分而治之。将UI细分为尽可能小的组件，使其可重用。将这些组件放入单独的项目/ dll中。示例组件可以是UserTable，它显示所有用户的列表（取依赖于接口IUserService）。

不要试图重用整个UI层，因为它注定要失败。原因在于，如果您尝试创建一个应该可配置且通用的U​​I，您可能最终会花费更多时间来使用可重用组件构建特定UI。最后，您需要添加小的“黑客”来对通用UI层进行微小更改以适应每个应用程序。它将以最终结果出现。

而是重用上面提到的组件来为每个应用程序构建特定的UI。