Question

假设我们在服务层之上有一些层，例如Web控制器。服务层依次高于DAO / Repo层。在上层，服务调用与repo调用一起使用。它在某种程度上打破了应用程序的分层，但是我们真的很想将findAll()等repo方法包装到服务方法中。我不这么认为。由于这种设计，是否有任何可能导致很多痛苦的缺点？交易问题？

Answer 1

我会回答你的问题并说 - 为什么没有这种方法的服务层？包装DAO方法是否真的很痛苦，如：

 public class PersonService {
 ...
     private PersonDao personDao;
 ...
     public List<Person> findAll() {
         return personDao.findAll();
     }
 ...
 }

客户数据 如果您不想将代表Person的数据实体发送回您的控制器，该怎么办？您可以将服务层中的数据映射到仅客户端所依赖的对象。

<强>联轴器您也在耦合图层。控制器层应仅依赖于服务层，服务层应仅依赖于DAO层。

<强>交易所有事务都应该在服务层处理（作为服务方法可以调用多个DAO方法）。

业务逻辑 所有业务逻辑都应该在您的服务层中。因此，您不应该通过直接调用DAO来绕过这样的逻辑。

我知道，对于像findAll这样的方法，它似乎毫无意义，但我认为关于图层耦合的观点会使这一论点失败。

Answer 2

是的，如果某些开发人员过去直接从其他层调用DAO层代码（即服务层或您正在关注的任何体系结构）作为解决方案，则可能会很痛苦：使用maven依赖项为您的项目创建4-5个不同的模块，并在SELECT DISTINCT r.ID, a.`Name` AS ArticleName, Articles.Amount, substr(r.City, 1, 3) AS ToCityName FROM Reservations r INNER JOIN Articles a ON r.Id = a.ReservationId INNER JOIN Articles ON a.ReservationId = Articles.ReservationId AND a.ArticleId = Articles.ArticleId WHERE a. NAME <> '' GROUP BY ToCityName, a.ArticleId, a. NAME ORDER BY ToCityName ASC中提及依赖项，以便不会从任何其他不正确的层进行调用。为了使它更清楚： - 如果您只想从第4层访问第3层，只需在第3层中为4添加一个依赖项，并且由于没有其他模块可以访问第3层，因此无法从中调用代码。

你肯定会有这样的例子。

混合DAO和服务调用

2 个答案: