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

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

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

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

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

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

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

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