Dao层Dao层实现类和Service层Service实现类的关系

Posted 2023-05-04

Dao层Dao层实现类和Service层Service实现类的关系

你好，
我就我个人的理解讲一下。希望对你有所帮助，
service是业务层 ，功能是实现你需要的业务
dao层是数据访问层，代表要操作的数据。
关系是一般都是调用某个service去实现某个业务，但是在实现业务的过程中。需要访问数据。也就是说。会在service中调用不同的dao，访问不同的数据，来完成这个业务相关的数据 处理。
之所以分层是为了解耦合。也就是为了后期维护的时候修改的时候可以更加方便
比如说 ： s事物需要访问 a b c 三个相关的数据。但是后面需要修改a 数据的处理逻辑，
如果你没有实现分层。那么就需要到service层中修改。
但是实现之后。就可以直接到访问a数据的dao层中修改相关逻辑.
类似mvc等分层架构。都是有这样的好处。
个人理解，如果有不足之处，可以指出，互相学习 ！ 参考技术A 1.Dao.java 和Dao.xml，Dao.java是接口（只有方法），xml是实现类（sql语句）。
2.service.java是接口，serviceImpl.java是遵循service接口规范的实现类。使用接口的好处就不提了。

在serviceImpl.java的方法中 调用 Dao.java方法 ，程序执行了Dao.xml中sql语句，对数据库进行操作。
在serviceImpl是用来做一些逻辑判断以及数据格式整合，返回到Controller层。 参考技术B 多态继承阿，调动子类方法。

facade service 层有啥作用

传统的J2EE系统的分层，一般是WEB展示层、Web控制层、业务逻辑层、数据访问层。
各层的职责比较简单，控制层仅处理Web参数与数据并传递给业务逻辑层。而具体的业务逻辑放在Service层即业务逻辑层中。同时，事务的控制边界也在这一层。Dao层对数据库的操作，更简单的理解为对SQL的拼装。
上面的各层泛泛来讲，都容易理解。具体用法上，又会有一些延伸。比如说Dao层，有的由一组Dao类来实现，有的则只有统一的Dao。这里的Dao类似一个工具类。比如使用ibatis2的时候，Dao可能只是一个Client及对应的xml。

问题:
在具体实施后，存在一些问题。往往一开始开发的时候，需求比较简单，各表都只需要增删改查。所以，往往类的创建往往是数据库导向的。即一张表对应一个Dao类/接口，进而又对应一个Service类/接口。
随着开发的继续，需求的补充，一些主业务表的Service往往贯穿整个业务系统的流程。自然而然，业务逻辑的代码开始膨胀。结果是主业务表的Service类异常的庞大。

因为领域模型是一个充血的模型，而目前传统的分层属于贫血的模型，转换差别比较大。如果是在原有的贫血模型基础上，再加入Facade层。
可是Facade层跟Service层到底有什么差别呢？如果没有严格的规则的话，最后只会导致Facade层是一个空壳。 参考技术A

使用Facade模式的是为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

将一个系统划分成为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小。达到该目标的途径之一是就是引入一个外观（Facade）对象，它为子系统中较一般的设施提供了一个单一而简单的界面。将各个子系统整合起来作为Facade，提供给客户端使用。

适用情况：

当你要为一个复杂子系统提供一个简单接口时。

客户程序与抽象类的实现部分之间存在着很大的依赖性。

当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。仅通过facade进行通讯。