对DAO和业务的一些心得

      B站上看到一个视频，讲的是DAO，但也让我明白了什么是业务。网上天天说业务，一问什么是业务要么搬概念，要么说工作有接触多了就理解了。对此真的很无语。
      
      首先，明确一点，DAO层的出现是为了降低程序耦合性而出现的。怎么降低的？
      
      如上图，一开始PC和移动端程序都使用JDBC访问同一个数据库，这体现了JDBC的重用性很好。但是一旦换个数据库呢，比如从MySQL换到Oracle数据库，是不是就需要重写JDBC的底层连接设置。
      
      重写就重写，也没什么，不就改几个配置文件的值嘛！但是，这里要注意，MySQL和Oracle的书写并不是完全相同的，这就意味着需要去重写SQL语句，甚至有时因这两者的不同。原先只需要一条语句就可以执行的语句变成多条，这里的改变就意味着调用者的调用策略就需要发生改变。
      
      那这个调用者是谁呢，每错。就是业务逻辑也是业务操做，指的是我们要增加一条记录，删除，修改，查询的操做。
      
      结合上文两端，是不是再换数据库的时候就有可能会发生，我们既有可能要重写SQL语句，还要重写调用这些语句的调用者所执行的逻辑。这在我们学校练手的项目上表现不明显，因为总的实现调用逻辑就几样子。
      
      但作为干这一行的人，需要将问题放大了来看。上述问题怎么放大来看？假如上述换数据库时，底层会出现的不止一个两个，而是成千上万。那重写起来是不是非常痛苦。
      
      那这种问题能不能避免？至少现阶段是不能避免的。但是我们可以去减少这种痛苦。从上文中可以看出我们是将调用者与被调用者放到了一起。也就是业务逻辑和数据操做，这里我们可以将其分为两层，业务逻辑只用关注我要去干什么就行不会出现重写调用策略的问题，怎么做的，去调用数据操做就行，不用知道底层是怎么做的。
      
      那为了实现上述的愿景，在数据访问这一层怎样才能是调用者的调用策略不发生改变呢？是提供接口：接口不涉及具体的方法实现。在写数据访问逻辑时，只需实现此接口从而重写方法就行。
      
      这样调用者只需要调用接口的实现就行。感觉很好，解决调用测略改变的问题。还有一个问题，当数据库改变，数据操做的SQL语句可能发生改变。意味着需要大量的去重写数据访问这层中实现了接口中的方法的方法体。
      
      那怎么办呢？回忆面向对象三大特征，封装、继承、多态。接口中的方法中使用的SQL语句可以归纳成几种通用的方法，将这些通用的方法抽取出来形成一个通用方法类。那么具体的数据操做，即是在接口方法实现中使用这些通用的方法。具体实现就是继承通用方法类同时实现接口。
      
      这里的这个通用方法类不为创建对象等，只为实现方法的继承，那么将其设置为抽象方法即可。这样在换数据库后，就不用重写大量的SQL语句，只需修改抽象类中的SQL语句即可。这大大的减少了重复书写的痛苦。