<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><head><meta http-equiv="Cont-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html><head><meta http-equiv="Cont

简介:       在一些项目开发中,为了使项目具有灵活配置的特性通常会使用配置文件,把一些常用的属性数据通过配置文件的方式引入系统。

      在一些项目开发中,为了使项目具有灵活配置的特性通常会使用配置文件,把一些常用的属性数据通过配置文件的方式引入系统。然而,当这些属性文件中数据变得越来越多的时候,问题还是出现了。

      加入配置文件的数据总结起来大致有以下几类:系统属性(比如系统首页地址等)、通用属性(比如性别等)、行业属性(比如官衔等)、以及用户自定义属性等。刚开始的时候,可能项目比较小,而且只是针对单一客户的,当客户有了修改这些属性数据的需求时,就直接去修改属性配置文件,谁也不愿意去考虑这写数据保存在属性配置文件中到底合适不合适。可是,随着项目逐渐完善,不同模块之间的属性配置文件个数越来越多,文件也变得越来越大,维护的工作量也相应增多,属性配置文件的问题就暴露出来了。

      无论是使用Properties文件,还是XML文件,或者其他的属性配置文件,当文件个数变多,数据量变大之后,维护起来都很费劲。尤其是项目面临产品化的时候,一个项目做成熟之后,可能会被很多客户使用,不同的客户有不同的属性配置需求,如果有几百甚至几千个客户,属性文件修改的工作量可想而知,给项目实施增加了不少难度。其实,最严峻的问题还不在这里,由于属性配置文件里保存的数据都是由固定格式要求的,如果格式错乱就不能正常解析,所以在修改属性配置文件的时候还需要额外小心,否则可能就会造成系统异常。

      对于属性配置文件暴露出来的问题,我个人认为,需要把系统属性相关的数据进行分类处理。我们不能单纯地认为因为属性配置文件有问题就不能用,更重要的是要搞清楚哪些数据才适合放在属性配置文件里。对于系统属性,如果是个性化的系统属性尽量不要放在属性配置文件中,包括行业属性,因为不同的地区可能同一个行业的业务也多多少少有差别,这些数据可以通过系统中的系统维护模块操作数据库来维护。而对于通用属性,相对比较固定,则可以通过属性配置文件来维护。可能对于一些小项目来说,系统维护模块还没有,但是对于一个成熟的项目,我个人认为,还是有必要包含系统维护模块的,提供一些维护系统的常用功能。

     近期,做的一个项目面临了这个问题,所以就写了下来,如果有更好的处理方式,就一起交流下吧,欢迎留言~

 

 

 

 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: