除了关系型数据库（企业级应用主要的数据持久工具）之外，企业级应用还需要其他的方式进行持久层操作。比如，数据保存在文件中、数据来自或者流向远程的其
他服务等。这样持久层的操作就会有3——5种之多（还分有事务管理支持的和没有事物管理支持的）。
怎么对这么多的操作进行有效的管理，怎么才能使持久层的变更只
限定在持久层的范围内，怎么才能实现业务逻辑开发人员在开发上不必具有很多的持久层框架经验（注1），还有就是怎样实现既可以利用强制和工具辅助的方式使一个新人能够开发出跟掌握持
久层开发的精髓的核心开发人员同样质量的代码（注2）又可以让老手开发起来非常快捷（熟练工种），更重要的是在业务逻
辑方面物质化、代码化积累公司的业界开发经验，这就是我们下面要讨论的问题。
我认为，要想实现持久层的修改（注3）与业务逻辑层分离。还要最大可能的把公用的东西抽象出来，最大可能的为培养业务专精人员提供基础，就必须
要有一个机制，实现把持久层的任务交给持久层去作。
这是什么意思呢？
就是在系统基础架构上，实现业务逻辑层和持久层的明显松耦合（业务逻辑层根本不必知道持久层到底是什么介质和实现方式）。
但是作为业务逻辑层的对象，数据的持久化操作是它所不能避免的东西，也就是说，它不可避免的会和持久层打交道。
那么怎样在代码的级别实现和持久层打交道还不跟持久层相关呢？
这就是要在下面给出的总体设计。在这里简单的介绍一下用到了三个技巧，一个是
IOC，一个是
Command模式，还有一个就是CallBack的概念。
IOC就是著名的好莱坞模式——你不用来找我，我会自己去找你的，而CallBack通俗一点说就是“你要做什么，你告诉我，到时候我会通知你，并把你想要的东西带来的”。
业务逻辑对象不可避免的要对持久层进行操作，但是它对持久层的操作本身可以抽象成为一个Command对象，由注入到业务逻辑对象中的DAO来负责操作。说通俗点儿就是
说，对业务逻辑对象（BO）而言它是把一个任务说明书（CommandCallBack）给了一个它自己都不知道是从哪里来的叫做DAO的家伙（IOC），然后跟他说：
“你拿着它，按它的指示去把这事儿给办了吧。”；业务逻辑对象知道“这事儿”是什么事儿，因为任务说明书是有名称的，但是至于任务说明书的内容，它就不清
楚了。具体的事情DAO和任务说明书清楚，但是业务逻辑对象只是一个交接。换句话就是说，通过这么一个交接手续，把持久层的东西还给持久层了。业务逻辑对
象只想知道“这事儿”办完的结果，事实上本来就应该这样。
整体设计上面，涉及到了几个持久层开发的基本的技巧，除了IOC、CallBack之外，还有DAO和容器管理。
DAO的模式其实也不是什么新鲜的摇滚Rock'n'Roll了，企业级应用要的就不是新鲜的东西（注4）。这个方式里面用的DAO是通用型的DAO，通
用型的DAO的优点就是接口统一，框架比较容易理解。但是缺点也十分明显，那就是它本身的灵活性是值得怀疑的，JDBC就是一个统一的接口，结果呢，直接
用它就会导致SQL遍布代码，这本身就增加了管理的复杂度，本来就是来封装持久层的，结果跟没封装没有区别，那么这个工作就是值得怀疑的。非通用型的
DAO倒是可以解决这个问题，但是非通用型的DAO就太灵活了，没有办法对它进行良好的封装，而且对于建筑在持久层的基础之上的业务逻辑层架构而言，这种
灵活性导致了只能对业务逻辑操作进行粗放式的封装，可重用的东西相对没有使用通用型DAO的时候多了。还有就是非通用型DAO的开发上面想要实现代码重用
也是比较麻烦的（需要良好的设计）。
至于容器管理吗，明天再谈。
注1：如果业务开发人员具有很多的持久层框架经验，当持久层框架更
换时，必然会造成他的极度不适应，这通常是系统移植成本很高的原因之一
注2 ：这是有可能的，类比一下C++和汇编语言，用Eclipse和用手工进行重构
注3：包括库表修改、框架更换和方式的修改——事实上，如果业务逻辑发生了修改，那么持久层可能必须得改，但是如果持久层封装的好的话，反之未必亦然
注4：公司重要的事情是盈利，根据技术辩证法，任何一个技术有有其优点也有其缺点，都有其适用和不适用的地方，新鲜的技术往往由于是对已有技术的革新，所
以在一段时间内会有很多潜在问题，作为爱好者去试用去跟技术的负责人联系当然是没问题，但是作为企业，对产品是质量要负有法律责任的，一般的公司当然都不
会愿意当新技术的小白鼠。相对而言，旧的技术由于拥有广泛的使用，优点和缺点广为人知，熟练开发人员也比较容易找到，可以在开发中规避其自身的缺点。当
然，不新鲜的也得看着要，得根据实际情况再作决定。