在一些项目开发中，为了使项目具有灵活配置的特性通常会使用配置文件，把一些常用的属性数据通过配置文件的方式引入系统。然而，当这些属性文件中数据变得越来越多的时候，问题还是出现了。
加入配置文件的数据总结起来大致有以下几类：系统属性（比如系统首页地址等）、通用属性（比如性别等）、行业属性（比如官衔等）、以及用户自定义属性等。刚开始的时候，可能项目比较小，而且只是针对单一客户的，当客户有了修改这些属性数据的需求时，就直接去修改属性配置文件，谁也不愿意去考虑这写数据保存在属性配置文件中到底合适不合适。可是，随着项目逐渐完善，不同模块之间的属性配置文件个数越来越多，文件也变得越来越大，维护的工作量也相应增多，属性配置文件的问题就暴露出来了。
无论是使用Properties文件，还是XML文件，或者其他的属性配置文件，当文件个数变多，数据量变大之后，维护起来都很费劲。尤其是项目面临产品化的时候，一个项目做成熟之后，可能会被很多客户使用，不同的客户有不同的属性配置需求，如果有几百甚至几千个客户，属性文件修改的工作量可想而知，给项目实施增加了不少难度。其实，最严峻的问题还不在这里，由于属性配置文件里保存的数据都是由固定格式要求的，如果格式错乱就不能正常解析，所以在修改属性配置文件的时候还需要额外小心，否则可能就会造成系统异常。
对于属性配置文件暴露出来的问题，我个人认为，需要把系统属性相关的数据进行分类处理。我们不能单纯地认为因为属性配置文件有问题就不能用，更重要的是要搞清楚哪些数据才适合放在属性配置文件里。对于系统属性，如果是个性化的系统属性尽量不要放在属性配置文件中，包括行业属性，因为不同的地区可能同一个行业的业务也多多少少有差别，这些数据可以通过系统中的系统维护模块操作数据库来维护。而对于通用属性，相对比较固定，则可以通过属性配置文件来维护。可能对于一些小项目来说，系统维护模块还没有，但是对于一个成熟的项目，我个人认为，还是有必要包含系统维护模块的，提供一些维护系统的常用功能。
近期，做的一个项目面临了这个问题，所以就写了下来，如果有更好的处理方式，就一起交流下吧，欢迎留言~