为什么会考虑json:

有没有这样的场景,当需要增加一个新配,假设配置存储在数据库中,会有什么问题?一般的做法大概就是增加一个字段,修改下映射,或者修改sql语句,然后需要回归所有功能同样在前端需要修改你的数据bean....一个浩大的工程似乎....

那么我们进阶下,假设现在换一种思路我们把数据映射到hashmap,那么首先数据库层的变动逃不掉的,接下来bean可以逃掉,但是带来的问题就是没有了类型...而且应用层需要大范围修改,更加不好的是我们需要对bean->map的一个映射,对象是白白创建的!!!

?

好了换一种思路吧,假设我们的配置项不太多,也就是10个,总字符不会超过500,而且读取都是单条的(这点还是很重要的)好了,那么我们现在在数据表中只建立一个字段,所有配置用json来传递,看看变化:

1) 不再需要修改数据结构

2) 那么也就没有了修改数据层代码的需要

3) 返回的就是map我们很开心的吧...

带来的问题: 类型怎么办?

java是类型语言不能搞得全部到处都是map吧,这个很难看,很不专业,关键你可能会在map里塞一个不可序列化对象!!! 好了,那我们来解决这个问题:

我想到了序列化这个东东,我们来改造下我们的所有数据bean的序列化对象吧,这样带来的结果就是map直接可以变成bean了,当然这中间对象是同事创建的一个json的map一个bean,好吧,效率虽然损失点,但是代码没得改动啦,很好很强大,当然注意这种方法是有侵入性的,也就是我们必须要解决整个的对象全部都是这个json序列化对象,否则就要exception了,这点和java的对象序列化原则一样.

似乎是完美的,但是注意这里有几个禁区:

1) 读取不能是一堆堆的,这样数据库层是很慢的,付出代价很高,所以只能搞配置或者一些模板性质的玩意

2) 不合适大量的自定义对象,这样使得嵌套很复杂容易出事,而且我必须对应翻译大量java的自定义对象,当然你可以用装饰器搞定,但是效率呢...

3) 不能对配置项进行数据查询和统计,这是它的知名弱点,如果你经常要知道a这个参数老是设置成1的用户多少,那么请绕行.

4) 补充的是领导提的,当你需要对所有数据做更新时可能需要停机做数据修正,而且效率很低!所以经常要干这个事情的时候请考虑是否能够承受这样的行为.

好了,尽管有些弱点,但是我们想想,它的优点很多:

1) 完全屏蔽了数据更改

2) 看起来很容易理解

3) 在应用中用起来多爽

4) 相比xml它的数据量很小啊,因此序列化成本并不高

5) 在多种语言中能用,这个当然得益于json本身的推广

?

好了,空谈了一把,目前还没有代码生成,尝试搞搞看看,感谢phprpc给我的灵感,呵呵