相信任何一个做企业级应用开发的程序员,都遇到过如何显示一个代码类型字段问题。通常来说有以下几种方式:

    1、硬编码。即在需要显示其文本含义的地方,直接显示相应文本。比如状态字段1,表示‘保存’。那么在任何一个显示的地方,我们都硬编码了“保存”这个中文文本;

    2、字典表。相信这是大多数程序员心目中的终极解决方案。你看,即能解决硬编码本地化文本的问题,甚至还能取出该状态的所有可能的值,显示在诸如下拉列表框中。

    乍看之下,貌似完美。但一琢磨,还是有些别扭的地方。比如:你在程序里,通常会以硬编码的形式,将其状态字段的code值写在程序中,并以某种public方法发布出去。这种做法没有任何问题。但是,如果你通过字典表来维护状态字段的code值和国际化文本的对应关系。这就有问题了。首先:字典表的维护一般是系统管理员来完成,他不是开发人员。系统管理员不可能翻开程序代码,找到所有相关的code,再将其维护进去;其次,OK,第一个问题实际通常都是我们开发人员将其初始化好了,系统管理员根本不需担心。那么,管理员是否可以增加、删除、修改相应的对应关系?技术上可以。因为我们肯定会将字典表的维护功能开放。但应不应该呢?我认为,不应该。why?

    为什么单独提一段,因为我觉得这个问题是字典表和下面这种方式最重要的区别。那就是,类似于这种业务状态的值,其本身并不是字典类型的数据。那么什么是字典类型的数据呢?我的定义是:和本系统业务无关的枚举值。比如我做一个车辆管理系统,主要负责车辆的实时定位。那么如果车辆有一个属性“燃油类型”,可能的值有90#,93#,97#。其实这个系统并不计算燃油成本之类的价格,那么,这个属性就完全符合字典属性的特征,其适合于采用字典表的方式实现;

    3、静态的国际化文件。在第二种字典表方式中,我们以业务状态字段举例,说明其不适合采用字典表的方式实现。那么应该怎么实现其本地化显示呢?静态的国际化文件。这在Java的世界里应该是个很现成的工具,Property文件就是用来做这个的。通过ResourceBundle接口,可以方便的将文件中的key和value提取出来,比如:1=保存。说明状态code为1的时候,其中文文本为“保存”。

    为什么非要用静态文件来存储其本地化信息呢?上一种方式中,我们解释了什么样的场景适合采用字典表。这里我们正好就可以拿来对比一下。因为状态肯定是静态的,是编译期就决定的。对于状态的增加、删除等,是要影响既有代码、流程、业务的。因此其也就不是可以让管理员动态管理的内容。

    有的同学可能要问了:“如果我采用第三种方式,那么有一种很常见的业务场景你无法满足,就是可能要在页面上显示一个状态列表的下拉框。我总不能读配置文件有多少对值吧?”其实,我感觉也是可以的,只是我还没试过,是否能行的通。不过我有另一种推荐的方式:在entity中,封装一个获得所有状态可能值的方法。因为我认为,一个entity的所有状态,应该也是其业务逻辑的一部分,因此可以封装成其本身的方法。你觉得呢?