我将我的网络应用程序划分为模块。每个模块通过 Facade 与其他模块进行通信,这是唯一的入口点。 Controller 还通过外观与模块进行通信。
Facade 中的方法采用一些 DTO 并执行一些业务逻辑。
在 90% 的情况下,到达 Controller 的请求会映射 1-1 外观方法的 DTO 参数。
我的问题是:使用相同的类在 Controller 中接收请求然后在门面中用作 DTO 是一个好的做法吗?
最佳答案
我不会说有绝对正确的方法来做到这一点。
如果您的应用程序相当简单,例如,只有用于创建和获取数据的数据库操作、简单的数据模型并且没有复杂的业务逻辑,那么使用相同的 DTO 可能没问题。这种情况大部分情况并非如此。
但是,如果您的应用程序需要处理相当范围的业务“用例”,那么最好将核心域层对象与用于与外部系统(例如 API 或 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
有助于您保持应用程序核心干净并与交互解耦。
希望这有意义并解决您的疑问。
关于java - Controller 和facade之间的通信,转换请求=> dto,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55900988/