在我们的应用程序中，我们有时必须为不同的客户进行少量的 GUI 修改：
（注意：虽然这些示例可能听起来很尴尬，但这些都是我们的客户要求的）
您如何处理这些情况？
目前我们以最常见的方式设计表单。在运行时，我们会进行调整，例如隐藏、调整大小或重新定位字段。 在输入验证时，我们会根据活跃客户验证内容。
【问题讨论】：
标签： user-interface forms customization
有几种不同的方法可以解决这个问题。但是，这取决于具体情况。
不要在同一个屏幕中添加不同的客户逻辑，而是为每个客户使用不同的屏幕，每个人都使用默认屏幕。
自定义构建或客户分支。虽然这可能会变得相当复杂。
完全按照您的做法行事，并在屏幕中嵌入客户特定的逻辑。
使用某种类型的规则引擎来驱动您的界面。
【讨论】：
本期有表单布局、数据库存储和可配置业务逻辑三个方面。
配置驱动的表单布局
可以通过将布局移动到描述符文件来实现表单布局的灵活方法。支持此功能的三个 GUI 工具包是 QT、WPF 和 XUL。但是，AFAIK Swing 不直接支持此功能。 QT Jambi 确实允许您在 Java 上使用 QT 作为 Swing 的替代方案，并且 QT 4.5 将提供 LGPL 许可。这不是一个纯 java 的解决方案，但如果这个和随之而来的 UI 代码重写是可以接受的，则可能是一种可能性。
配置驱动的表单布局的优点是可以进行自定义，而无需为每个客户维护单独的构建，因此即使您有现有的代码库，您也可能希望检查是否存在业务案例采用这样的工具包与维护多个特定于客户的构建。但是，对于编译型语言，您可能仍需要为生成的表单代码设置某种插件框架。
可配置的数据库存储
这更复杂。您可以通过三种方式做到这一点，它们各有利弊。
第一种方法是在表上设置一系列“用户”字段，例如“用户 1”、“用户 2”等。表单上的配置字段可以映射到这些字段 - 以及通用用户现场测绘设施应该不难实施。从数据库查询的角度来看，这是最有效的，但受到可能字段数量有限的限制。如果您有“User1”到“User20”字段，则只能支持 20 个用户定义的属性。此外，它们必须是很好的、宽泛的泛型 varchar，因此您不会从数据库中获得类型安全。
第二种方法是将属性表挂在实体上。这不会为您提供类型安全性，但确实可以让您拥有任意数量的属性。为此构建一个通用处理程序也是非常可行的，但是当您对属性表进行多次连接时，查询性能会受到影响。
在 XML blob 中保留用户定义的字段。这没什么可推荐的，因为它使通过数据库访问数据变得更加困难。但是，我已经看到它完成了。
可配置的业务逻辑
这是一个更棘手的问题。在不添加自定义代码和更改构建的情况下，您有几个选项来执行可配置的业务规则：规则引擎、脚本语言或一组标准的开/关功能，例如必填字段。
规则引擎：您确实必须从头开始设计您的应用程序才能使用这些引擎，它们有其自身的局限性和弱点。 ILOG，这个领域的老牌，也是相当昂贵的。对于 java，JESS 可能是一个选项。
嵌入式脚本语言：通过为 Jython、Groovy 或其他一些 JVM 友好的解释语言添加解释器，您可以为系统编写插件，而无需发布新的构建。仍然会产生一些测试工作量，但这可能是整体维护的胜利。
功能的开/关配置。这是最不灵活的选项，但相对简单，并且在外部依赖和许可成本方面增加的相对较少。如果您尝试将配置改造成最初作为定制应用程序的应用程序，它也可能是您唯一的选择。
以上都不是
如果答案是“以上都不是”，那么您可能会被自定义构建所困扰。在这种情况下，为表单创建一个插件架构，这样您至少可以将客户特定的项目隔离到一个单独的模块中。
【讨论】：
我能想到 4 种方法：
如果这是不可能的......
【讨论】：
我不确定这是什么类型的应用程序，但是当我们收到有冲突的功能请求时，我们通常会分支每个客户端的版本，并在每个分支中只包含相关代码。
您是否使用任何类型的代码控制/版本控制系统？我们使用的是 SVN，它允许您在更改主代码时更新每个分支，因此代码永远不会过时。
【讨论】：
我会做一些类似于 MS Access 内的表单创建屏幕的操作，允许客户自己添加/删除/修改和设置输入。它还允许他们设置哪些字段是强制性的，哪些不是。这意味着您需要在前端做更多的工作，但在后面做的更少。
【讨论】：
我建议使用某种插件系统。对于每个客户，只需创建一个插件来修改应用程序的 UI 并在启动时加载它。我不是Java程序员，所以恐怕我不能发布任何特定的代码sn-ps。
【讨论】：