DAO是J2EE设计模式中一种重要的设计模式。它上与BO（Business Object）业务逻辑层相连，下与数据源逼近，其重要性就不言而喻了。
举一个简单的例子：分页。分页是系统中非常常见的功能模块。我们用两种方式来模拟一下这个功能：纯净的JSP，还有JSP+DAO。
纯jsp的方式：我们会在页面里直接直接上sql语句：SELECT ...FROM ... LIMIT n,m。如果我们系统中有好多个模块都要用到分页的功能，那这块管理分页的程序会立马出现在好多个页面上，这时候再加上数据库的连接关闭，或者其他的业务代码，我们的页面会显得很乱，不好维护。而且从代码复用的角度来说这样就不很合理。
下面我们看一下：JSP+DAO：我们可以完全把与数据库有关的操作交给DAO层来管理，数据库的连接关闭，分页的逻辑，或者你的jsp页面中还有其他操作数据库的业务代码，不要犹豫了放心的交给DAO吧！这样我们的页面上就不会出现相当恶心的有关数据库操作的代码了，整个JSP页面清爽了好多。而且其他模块在使用分页功能的时候就可以直接去调用已经封转好的DAO了。可能例子有点极端，但是只是想说明一下DAO多么的有用，希望目的达到了！
我们来总结一下dao在我们系统中都做了什么：DAO完全隔离了系统中业务逻辑层和数据访问层。数据访问集中在DAO这一层中，方便我们进行集中的管理，系统的层次性更好了，为后期的系统维护提供了一定的便利。DAO 还有助于提升系统的可移植性。独立的 DAO 层使得系统能在不同的数据库之间轻易切换，底层的数据库实现对于 BO 来说是不可见的。数据移植时影响的仅仅是 DAO 层，切换不同的数据库并不会影响 BO，因此提高了系统的可复用性。
DAO其实也是面向对象的一种设计，因为系统中所有的操作数据库可以看作是同一种行为，所以我们就可以”面向对象的“抽象出一个专门的对象管理负责这一块。系统中如果有数据库的操作，那就很便捷了，对DAO说：”我要操作数据库了，给我连上数据库，然后给我拿出我昨天存入数据库的数据...“。然后你就等着就行了。听起来非常的爽，用起来是更爽。
但是这种“爽”是建立在对DAO正确的封装和使用的基础之上的。如果你用的不合理，也会非常的别扭。
DAO（Data Access Object 数据传输对象）是若干个原子操作组成的集合。他的特点是执行最基本的数据库操作CRUD（增删改查）。我们在设计程序的过程中不要对DAO层施加任何的业务逻辑，如果这样的话你抽象出这样的DAO层就完全没有意义了，那么直呼它为service或许更合适，业务逻辑专门有我们的service层或者action层。反正DAO肯定不适合处理业务，好像赵本山小品中”公鸡下蛋“，你让它干了它不该干的事情，他心里能好受吗？我不知道程序要是心里不好受了他会干出什么坏事，破坏程序的可读性，减低代码重用率，增加代码维护的难度....因为我还是一只菜鸟，所以我不能预知后果！！呵呵姑且就当后果很严重吧！不负责任的猜测程序的效率也可能会受到影响：因为把业务交给了DAO，DAO里离数据库最近，难免不了数据库“替”DAO处理业务逻辑，那么相当于mysql也做了不该干的事。
Java是一种”大腕“语言。就拿一个登录框架来说，有的人两个个页面可以搞定，有的人却可以想到用SSH来“架构一下”。我真正接触java的时间也差不多有一年多了，我也深有体会（说深有体会其实是骗人的，上面说了我还是一只菜鸟，哪能深有体会呢）。但这不是java的缺点，而是好多人（更准确的说是像我们这样的一群菜鸟），努力地想使用更多的东西比如说SSH来炫耀自己的“功力”。真正的架构应该根据需求来定，好比说一个登陆框架你就没有必要SSH了，但是如果你想做一个面对用户千百万，程序代码百十来万行，那么你还用纯jsp，那不是开玩笑吗！
合理利用java中的各种模式和框架，不过说起来容易做起来难呀！！纯个人胡言乱语，请前辈们不吝赐教，感激不尽。