我正在开发一个项目,其任务是创建一条结账活动门票的路线。在这种情况下,我有一个控制器,用于接收包含订单数据、客户信息、票据和付款详细信息的请求。随后,我将此请求传递给我的用例以执行任务。
但是,我有一个用例,我创建一个订单,它是一个实体,并且我需要另一个用例来接收订单以使用票证实体验证票证。稍后,如果验证成功,订单将传递到支付用例,创建交易实体。所有这些都是在同一个控制器中完成的,有点像下面的代码:
export class CheckoutController implements Controller {
constructor(
private createOrder: CreateOrder,
private makeTicketValidate: MakeTicketValidate,
private makePayment: MakePayment,
){}
async handle (request: CheckoutController.Request): Promise<HttpResponse> {
const order: Order = this.createOrder(request)
// Here i receive the Order entity and step to the next use case
const isValid: boolean = await this.makeTicketValidate(order)
if(!isValid) {
return badRequest()
}
const transactionId = await this.makePayment(order)
if(!transactionId) {
return internalServerError()
}
return ok({transactionId})
}
}
我是否有可能违反了该控制器中的一些干净架构原则?
通过控制器将 Order 实体从一个用例传递到另一个用例是否有代码味道?
在同一个控制器中拥有多个用例是否正确?特别是考虑到在一次操作中处理大量数据时?或者我应该将它们分成单独的控制器?
我是否需要通过presenter返回数据,或者我可以简单地在控制器中使用用例本身的返回来将HTTP响应发送到前端吗?
提前感谢所有回复的人!
我一直在考虑使用“订单”实体的数据访问对象在用例之间传输数据。
或者,我可以分离控制器来划分职责。
从单个控制器编排多个用例时,您没有违反清洁架构的规则。或者,您也可以从控制器仅调用一个用例,然后使用第一个用例中的第二个用例。
在清洁架构中,通常用例消耗“请求模型”并返回“响应模型”。然而,直接在用例之间传递实体可能是一个务实的决定,不会违反清洁架构的规则。
控制器充当从“外部”到应用程序逻辑的 API。因此,分离控制器的主要驱动因素应该是您是否想要从应用程序中提供不同的 API 接口。
不建议直接从控制器或演示者返回响应模型或实体,因为这会导致您的应用程序内部设计暴露在外(Web API、Web UI、测试)。由此产生的调用者/UI 和应用程序逻辑之间的耦合使得进一步更改应用程序逻辑变得更加困难,甚至不可能。 相反,控制者和演示者应该充当“反腐败层”。 (另请参阅:https://youtu.be/iD4wns3yH44)