控制器和门面之间的通信，转换请求 => dto

Question

好吧，我将我的 Web 应用程序划分为模块。每个模块都通过 Facade 与其他模块进行通信，这是唯一的入口点。控制器也通过外观与模块通信。外观中的方法需要一些 DTO 并执行一些业务逻辑。在 90% 的情况下，控制器映射 1-1 外观方法的 DTO 参数的请求。我的问题是：使用相同的类在控制器中获取请求然后在外观中用作 DTO 是一种好习惯吗？

Answer 1

我不会说有绝对正确的方法可以做到这一点。

如果您的应用程序相当简单，例如，只是用于创建和获取数据的数据库操作、简单的数据模型并且没有复杂的业务逻辑，那么使用相同的 DTO 可能会很好。这种情况大多不是真的。

但是，如果您的应用程序需要处理相当多的业务“用例”，那么最好将您的核心域层对象与用于与外部系统（如 API 或消息队列）交互的对象分开。

如果你举个例子（有点做作的用例来说明我的观点）：

假设用户现在可以通过 ReST 端点在您的应用程序中创建客户，并且有一个定义良好的请求模型：

class CustomerDTO {

  private String firstName;

  private String lastName;

  private String companyId;

  private String email;

  private List<String> subscriptions; // customers subscribe to services

}

假设，您的域模型：

class CustomerBO {

  private String name;   // firstName + lastName

  private String companyId;

  private String email;

  private List<String> subscriptions; // customers subscribe to services

}

稍后，如果您想通过从消息队列或 CSV 文件中读取实体来添加创建实体的功能 - 您的应用程序可能是下游系统从另一个应用程序获取馈送。在这种情况下，您与 API 用例有以下区别：

• 每个客户只有 1 个订阅（总是）

• 名称作为单个字段发送

• 没有电子邮件，因为这些客户不是真正的人类用户（也就是说，没有要发送的电子邮件，没有登录等）

因此，您的请求模型如下所示：

class FeedCustomerDTO {

  private String name;

  private String companyId;

  private String subscriptionId;

}

现在，应用程序核心只接受CustomerBO. API 和 Feed 模块将请求模型转换为一致的域模型。您可以看到，CustomerBO在这两个用例中保持一致有助于您保持应用程序核心清洁并与交互分离。

希望这有意义并解决您的查询。