DAO模式

Data Access Object：数据访问对象

首先，你的应用程序，肯定会有业务逻辑的代码。在三层架构的web系统中，业务逻辑的代码，就是在你的Service组件里面；在我们的spark作业中，业务逻辑代码就是在我们的spark作业里面。

如果说，你不用DAO模式的话，那么所有的数据库访问的代码和逻辑会全部耦合在业务逻辑代码里面。比如，你的业务逻辑代码中，可能会充斥着JDBCHelper，定义SQL语句，处理查询返回结果等等代码。会导致业务逻辑和数据访问严重耦合。导致以后如果你只是想修改数据访问的代码，那么还得在一大堆业务逻辑的代码中去找，找到这段代码，然后去做对应的修改。

因为我们要将数据库访问的代码，封装在DAO中，然后呢，业务逻辑的代码，就可以直接去调用DAO组件，实现数据库操作的逻辑。如果这样做了以后，那么在业务逻辑的代码中，就不可能出现SQL语句、查询结果处理等等这些东西。当后面对系统进行维护的时候，如果你只是要优化一条SQL语句，那么你肯定不用跑到业务逻辑的代码里面去找到这条SQL语句，然后去修改它。。。

只需要到业务逻辑代码调用的DAO组件里面去，找到对应的SQL语句，修改，即可。

引入了DAO模式以后，就大大降低了业务逻辑层和数据访问层的耦合，大大提升了后期的系统维护的效率，并降低了时间成本。

我们自己在实现DAO模式的时候，通常来说，会将其分为两部分，一个是DAO接口；一个是DAO实现类。我们的业务的代码，通常就是面向接口进行编程；那么当接口的实现需要改变的时候，直接定义一个新的实现即可。但是对于我们的业务代码来说，只要面向接口开发就可以了。DAO的改动对业务代码应该没有任何的影响。