开发学习心的

 中国教育网,前台完成,但是,需要很多的修改,周五开始了,后台用户管理,收获不多,周末,没有再做,而是抽点时间去研究一些具有代表性的框架,这段时间研究的是spring,举步维艰,顺便把鼎鼎大名的nunit给学会了,一用之下发现果然比vs2008内嵌的测试工具好用的多,而且人性化多了,独立性强,这也算是这周的一个很好的收获,周日起来的很晚,刚起来,我又投入到spring中去了,我还是失败了多次.有放下了,顺便拿起一本我久违的"重构",开始了一个很有代表性的例子,记得第一次看的时候没有什么感觉,第二次的时候,只是觉得这个结构很完美,而且很是值得学习,这次,不大一样,我按照作者的思路我一步一步走了下来,记得其中有两句话"如果多次引用一个对象的数据的时候,就大胆的将该段代码提炼,移动到该对象内部"给了我很大的启发,我以前做了不少项目,但是每次做到,数据访问层到业务层的时候,业务层什么任务都没敢,但是数据访问层做的事情很多,有点不对劲但是有那不出好的想法来,这次我想到了一些,但是需要在实际中应用才得以发挥啊,然后想想现在的IT行业里面有很多的开源框架,比如说我这一次在中国教育网里面用到的nhibernate就是其中一个鼎鼎大名的数据库持久化组件,昨晚突然想到了为什么这个东西会出现,记得我上面体会到的那句话吗,
如果多次引用一个对象的数据的时候,就大胆的将该段代码提炼,移动到该对象内部,我是不会忘记的,永远,

因为在数据库访问对象是需要将大量的数据复制到实体类中,于是干脆将类读取器给了这个实体类,但是,从面向对象的角度考虑,这个封装数据是一个不小的任务,于是为了降低耦合度,必须将他给独立出来,但是独立出来后新的问题有来了,如何能够将数据库中不同类型的数据准确的复制到他所对应的实体类中呢,我尝试着想过,

方案1:通过反射读取到这个实体类中的各个属性,以及他们的详细信息,包括类型等等,然后再得到数据库表中的字段的详细信息,让他们匹配,但是这样虽然是可以解决问题,但是,显得很麻烦也有点臃肿的感觉.

方案2:同过配置文件详细描述表与实体之间的关系,这也是现在很多框架的采用的办法,这样做确实很好,虽然多出了不少xml文件,但是比起解决的问题,我们还是应该选择前者.

 

    于是我想到,该用数据库持久化得更合理的理由了,既然我们都得我上面说的那样做,为什么不将其抽象呢,既然都抽象了,与其自己写的那些个很烂的代码,为什么不用别人而且是很多高手设计出来的很优秀的框架呢,

所以我们改用数据库持久化.

 

    那天,坐车的时候,突然想到一句话话"如果两个东西接触太密的话,那就意味着要分开,必须介入一个中间层",我记得不大准确了但是大概就是这么个意思,使我想到了,现在公司都采取让客户不要直接接触开发人员,而有专门的人员来对付,那我们的程序中,当两个层级有太多的耦合的话,是不是也该考虑分开呢,这个是我对软件的设计有了一种新的认识.

   呵呵.