什么是制作图形用户界面的正确方法

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

谢谢

来源

2011-11-14 PTBG

这是一个非常有效的解决方案。对于许多精心设计的网络应用程序，这正是发生了什么事情。客户端是某种Web浏览器，业务逻辑运行在中央服务器上。 – Marvo

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

这对于桌面应用程序来说有点不寻常，但它是完全可以接受的。这个解决方案的优点是，它可以让你为不同的平台编写多个富客户端（例如移动应用，Windows应用，基于浏览器的应用等）。需要与后端交谈。例如，它需要一种获取对象和保存对象的方法，并且需要从后端接收UI需要更新的通知。

来源

2011-11-14 19:20:39

设计合理的服务和表示层应该完全没问题。总结利弊，在我看来：

优点：不绑定物理逻辑

UI，所以逻辑层可以是远程（为多个客户端，甚至独立BL服务器）。我们称之为“业务逻辑位置独立性”。
可以创建不同版本的GUI（不仅可以是图形化的 - 可以将BL作为服务公开，例如作为提要或报告端点），“GUI平台独立性”以及SOA方法。
可以在BL和GUI之间添加代理 - 用于安全和缓存目的。或负载平衡器在应用程序场之前。或者在重大BL更改后支持“旧”客户端的适配器。（“弹性和故障安全”）？
部署可能在一定程度上更容易（修复UI中的错误不会影响BL层 - 只是二进制模块无关的结果）
能够添加“脱机模式”到GUI。

缺点：

你增加一个连接链路，这可能是又一个失败点，以及一些精力应该花在用于测试。
GUI和BL之间的数据流量增加，可能还有更多的序列化工作。
需要跟踪通信协议更改和正确的协议版本维护。
（代理能力的负面）在GUI和BL之间进行中间人攻击的可能性。

来源

2011-11-15 12:59:23 mikalai

取决于应用类型。

桌面应用程序

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

Web应用程序

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

套接字

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

更新评论

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

不要尝试，因为它注定要失败的重用整个UI层。原因是，如果你试图创建一个应该可配置和通用的UI，那么你最终可能花费更多的时间，而不是使用可重用组件构建特定的UI。最后，您需要添加小的“黑客”来对通用UI层进行微小更改以适应每个应用程序。它将最终成为一个emss。

重复使用上述组件为每个应用程序构建特定的UI。

来源

2011-11-15 13:13:19 jgauffin

我们所有的应用程序都是桌面应用程序。我想要做的是使GUI尽可能抽象和可配置，以便我们可以为每个应用程序使用它（最少的编码），并最终可能将它们作为一个套件进行组合。因此，除了将BL与UI分开并使用IPC进行通信之外，您如何建议我实现抽象UI的目标？ – PTBG

阅读我的更新。 – jgauffin

你说服务器和GUI在同一台机器上没有意义。为什么？这很不寻常，但我不会说它没有意义。 –

什么是制作图形用户界面的正确方法

回答

相关问题