持久层与ORMaping

 最近在做一个项目用到了持久化层。学到了些东西，跟大家分享下：

持久化就是把数据保存到可掉电式存储设备中供之后使用。我们每天都在用的oracel就是一个持久化工具。通过它我们将数据持久化到磁盘上。

有了持久化为什么还要持久层呢？
主要是为了解决以下几个问题：
1、如果业务层发生变化，比如需要将客户端程序从C/S迁移到B/S，我们的持久化代码是否要重新编译。
2、如果底层数据持久化机制发上了变化，如从oracle数据库更改成sqlserver或者用于测试的小型数据库mysql，我们的持久化代码是否要重新编译。

从本质上讲持久化进化到持久层的目的就是为了解耦合，实现业务逻辑和数据逻辑的分离。
举个很简单的例子：
我们复制文件，有可能复制到软盘\U盘\甚至是网络上的任意一台电脑的硬盘，如果按照开发人员的思维方式就要写一堆if/else来判断设备类型，如果更完善一点还要考虑并发，同一时间不能向一个设备发数据，调度好线程。但是实际上我们只需要Ctrl+C/Ctrl+V就搞定了，操作系统帮我们做好了一个持久化层。将我们的业务逻辑（拷贝文件）和数据逻辑（传输数据）分离了。

设计得好的持久成可以达到以下目的：
1、数据存储逻辑的分离
业务层代码不会出现数据操作的代码如insert/update/select，只需要编写业务代码如：
Customer c=new Customer();
c.setName("jack");
c.setAge(20);
saveandupdate(c);
使得开发人员可以更好的专业划分，另外测试起来也相对容易
2、更好的性能
成熟的持久化层可以提供数据库连接池\语句cache\数据cache，减少数据库的查询压力。
数据库连接池：每次数据库连接都需要建立socket、验证密码\权限、记录日志、分配cpu内存等等，这是相当耗费资源的。  如果仅仅为了一条查询语句就要建立连接然后释放连接那就太浪费了。数据库连接池就是将暂时不用的连接不进行关闭，保存下了，以备下次直接使用。
语句cache：一般情况下我们认为update语句很快，也就一眨眼的时间，但是这一眨眼的时间数据库为我们做了很多事——  sql语法检查、语义分析、创建执行计划等。大型的系统由成百上千的终端操作数据库，而实际上操作最多的表也就十几个，运行的语句也就几十种。如果将这些语句也缓存起来，性能也能够提高很多。
数据cache：这是最常见的，如果数据库中的数据没有变化那就不用从数据库中select了，直接读内存就好了。减少了网络传输、内存与磁盘数据交换等开销。

说了这么多持久层的功能，大家可能觉得说的这么好，设计开发这个层一定很困难。那是当然了，但是这个不用我们自己从头来搞，这里就引出了ORMaping。先介绍一下ORMaping的理论。

ORMaping就是对象关系映射。ORMaping发展到现在已经出现了很多好的成熟的产品，而且很多都是开源的免费的。采用这些产品可以减少乏味的代码/更加面向对象的设计/更好的性能/更好的移植性。

一般的开发步骤是：
1、编写ORMap配置文件，一般是xml的。这是比较耗时的，但是可以进行迭代开发，一边开发一边修改（建议采用自动测试工具Unit系列，每次修改完成回归测试一下建立信心）。

2、借助工具，根据配置文件生成数据库ddl，以及实体类代码，比如同时生成Customer表和Customer.java源码， 表有字段name,相应的Customer.java有属性name和相应的方法getName()/setName(String)。 对于遗留系统，可以借助工具连接数据库反向生成配置文件和实体类代码，十分方便快捷。

3、编写提供给业务层的方法，其中涉及到事务的处理、异常处理、操作实体类，类似于以前的业务开发，但是 完全不涉及到sql语句（通过配置文件ORMap产品和数据库在底层进行sql交互，对我们来说是透明的），完全的面向对象代码。这步 稍微费点时间但是相对于以前的业务开发便利了太多。