我应该在哪个层，Dao 或 Service 中解析 Rest Client 响应？

Question

我有自己的服务调用第三方休息服务，该服务返回基于文本的响应。基于文本的响应不是正确的服务响应，需要解析内容和错误。为便于讨论，假设第 3 方休息服务无法更改。

鉴于这些情况，我想知道我是否应该将该解析连接到应用程序的 dao 层或服务层。我知道服务层应该包含您所有的业务逻辑，但我觉得如果我不进行解析在我的道层我正在泄漏。在这种情况下，为了解析/转换的目的，可以在 dao 中有逻辑还是应该在服务层中完成？

任何建议表示赞赏。

public void MyDao {

     private RestTemplate restTemplate;
     private ResponseParser responseParser;

     public myDao(RestTemplate restTemplate, ResponseParser responsePaser){
          this.restTemplate = restTemplate;
          this.responseParser = responseParser;
     }

     public MyResponse sendRequest(MyRequest myRequest){
         ResponseEntity<String> responeEntity = restTemplate.exchange(...);
         String body = responseEntity.getBody();
         return responseParser.parse(body);
    }
}

或者

public void MyDao {

     private RestTemplate restTemplate;

     public myDao(RestTemplate restTemplate, ResponseParser responsePaser){
          this.restTemplate = restTemplate;
     }

     public String sendRequest(MyRequest myRequest){
         ResponseEntity<String> responeEntity = restTemplate.exchange(...);
         return responseEntity.getBody();
    }
}

public void MyService {

     private MyDao myDao;
     private ResponseParser responseParser;

     public myDao(MyDao myDao, ResponseParser responsePaser){
         this.myDao = myDao; 
         this.responseParser = responseParser;
     }

     public MyObject process(MyRequest myRequest){
         String response = myDao.sendRequest(myRequest)
         return responseParser.parse(response);
    }
}

Answer 1

以下是我对设计的看法和看法。

• DAO 是一种抽象持久性操作的模式，应该仅用于持久性操作。
• DAO 模式有助于从客户端的数据源中抽象出持久性机制/操作或数据访问操作，并且设计遵循 SRP，从而使向新的持久性类型的过渡变得容易。并且持久性机制/数据源的更改保留在 DAO 层中，而不是上升到服务层。
• 服务层负责处理和计算数据的业务操作。它使用 DAO/存储库/客户端来获取操作所需的数据。

考虑到上述几点，以下是我对现有设计的看法以及我将如何做。

• 正如 chrylis 上面提到的，DAO 是一个数据访问对象，无论数据是从 DB 还是通过 HTTP 获取，都无关紧要。Oracle 关于 J2EE 模式的文章如下：

使用数据访问对象（DAO）来抽象和封装对数据源的所有访问。DAO 管理与数据源的连接以获取和存储数据。

它进一步写道：数据源可以是像 RDBMS 这样的持久存储、像 B2B 交换这样的外部服务、像 LDAP 数据库这样的存储库，或者是通过CORBA Internet Inter-ORB 协议 (IIOP) 或低级访问的业务服务。插座。

• 考虑到这些，我将从 DAO 进行调用，解析响应并将业务对象发送到服务。
• 考虑到 SRP，服务不应该知道通过 HTTP 进行的调用/从平面文件进行的数据库调用/读取。它应该知道的是，一旦我查询数据，我就会从 DAO 获取包含所需数据的对象。
• 如果服务负责解析，那么如果明天数据源发生变化并且您拥有原位数据怎么办？现在 DAO 发生了变化，因为现在它与数据库通信而不是发出 HTTP 请求。您无法再返回字符串表示形式。您需要一个数据映射器，并将发送回某种对象表示形式，这意味着您的服务类也会发生变化。因此，只要更改数据源，不仅会更改 DAO 中的代码，还会影响业务层，从而破坏 SRP。
• 这么说，开发时间不长，也没有软件工程背景（我知道数据访问对象只能来自数据存储，但感谢 chrylis 的评论让我阅读更多内容并思考数据源和数据存储之间的区别），我总是更喜欢将其命名为 Client -> RestClient 并进行调用并将我的数据库操作保留到 DAO/Repo。原因是，明天阅读起来很容易。一看类名，就很容易理解它在做什么或者该类可能处理什么类型的操作。

所以，是的，调用和解析应该发生在 DAO/客户端中。

Answer 2

严格来说，Dao层用于管理持久性机制中包含的信息，例如：数据库、LDAP 等。因此，当您处理外部端点时，“包含”服务中的功能是一种更广泛使用的方法。

回答你的问题，第一个选择是更好的选择。

1. 您将所需的业务逻辑包含到知道外部端点返回的格式/信息的类中。

2. 使用上述类的外部类将管理一个众所周知的对象（而不是原始字符串值）

3. 外部端点中的某些类型的升级（例如，响应格式的更改）可以在 Dao 类中更好地管理，而不会影响使用它的其他类。