《鲁棒的数据库持久层设计》读书笔记01-持久层的类型

文中提到了三种在持久化方面比较流行的方法:

1.将业务层、用户界面层和数据访问层混在一起，SQL代码在程序中随处可见。

这种方式对于较小的项目在项目开始启动的时候会使开发保持较高的效率，每个人下负责的代码相对都是独立的，不需要花太多时间去进行模块之间的协调。但是随着项目的扩大，模块的增多，以及开发人员的增加，会出现大量的代码重复，一点小的变更可能要修改程序里的很多地方，如果管理不当甚至造成遗漏，给程序的品质带来很大的风险。

举个例子：一个管理系统中经常会用到个人信息的读取这个操作，而且可能被很多模块用到。如果每个开发人员自己写自己的或者简单的复制粘贴，到后期，如果个人信息表发生了变更，那就需要修改每一个用到个人信息的地方，工作量是非常大的。

2.将业务类和数据类进行分离，将数据的读取和业务流程分别处理。我觉得这就是比较流行的三层结构。文中提到这种方法只适合少于40或者50个业务类的小系统，对此我也不能完全理解。对于三层结构和ORM孰优孰略有很多争论，由于这两种体系都没有真正的使用过所以我也没有什么特别的想法。

3.将对象映像到某种持久机制并且对关系数据库的简单改动并不影响你的面向对象代码的一个鲁棒的持久层设计。这里把这种方法说的很神，不知道实际是不是这样的，等把这篇文章读完了也许就有个大概的结论了吧，呵呵。

继续努力吧！