我的应用程序配置非常分层,非常适合单个XML.很快(YAGNI,Yeh)这些信息的一部分将远程被其他应用程序使用,这需要一个数据库.
因此,我开始设计数据库表并将它们映射回应用程序的类层次结构(使用EF).然而它成了维护的噩梦.
我很想听听其他人在考虑这个问题时的经验,谢谢.
我们有很好的经验,可以将配置存储在数据库中,用于长期运行的应用程序(如网站和服务).好处:
您可以远程安全地编辑配置(用户/密码)
应用程序可以select max(lmod) from config自动或通过信号(ping网页或在某处创建空文件)轻松获取更改()
应用程序每个环境(dev,test,prod)只需要一个配置项:要使用的DB.如果您有应用程序服务器,则您的应用程序可以免费为所有环境配置.
主要问题是编辑,如果你有一个复杂的,分层的配置结构,默认,列表和继承.我们的方案:
配置表包含以下行:Application varchar(32),Key varchar(512),Value varchar(4096)
每个环境一个DB(本地开发人员机器,开发测试,集成测试,生产)
关键是分层(option.suboption .... name)
默认值使用"option .name"(例如,"jdbc .driver",因为我们只使用一种类型的数据库)
列表存储为字符串,由换行符分隔.
地图作为字符串存储,"name = value \n"
有一个实现可以从文件中读取配置(用于单元测试).将键的每个层次结构映射到元素(......)
配置对象隐藏这些细节,因此应用程序只适用于对象.
特殊类负责在发生更改时重新读取配置.通常,我们会在一天中的某个时间更新配置,并且定时作业将在数小时后重新加载.这样,我们就不需要同步配置方法了.
但是,备份和更改历史记录是一个问题.我们通过在VCS中使用XML文件来修复它,然后将其"上传"到数据库中.这样,我们可以在上传之前验证生产配置(通过在开发人员计算机上使用一组特殊的单元测试).当它在夜间被激活时,它通常立即工作,负责应用程序的操作员只需要进行一些测试.
恕我直言的配置应该存在于文件中,文件适用于人们,并且它们对计算机没问题.数据库可以很好地处理大数据,但它们对人类的东西来说太过分了.这两者通常是相互排斥的,当你尝试将它们组合起来时,你会得到类似注册表的内容 - uggh.
为什么不将配置保留在文件中,并围绕它构建DAL和服务层,以便您的应用程序可以使用它.假设您可以托管到中央服务器,如果没有该文件的多个副本.
京公网安备 11010802040832号 | 京ICP备19059560号-6 