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