关于将HttpRequest和HttpResponse传递给服务层的想法？

Question

我有一个CommerceService模块来帮助处理常见的订单处理功能，其中包括通过Authorize.net，Paypal和Google Checkout等提供商进行支付授权。它提供了一个简单的界面，例如placeOrder（Order），并且可以解决繁重的问题。

本地付款服务提供商可以直接推出，但是Paypal和Google提供远程支付服务，所以对于Paypal，用户可以离开您的网站，在那里付款，Paypal会发送Http通知以挂钩您的订单流程

我遇到的问题是处理这些通知。理想情况下，最简单的方法是将HttpRequest对象传递给服务层，让服务使用handleRemoteOrder（Request，Response）来完成订单，而不是强迫前端担心这一点。但是将请求和响应传递给服务层似乎是非常错误的。

我考虑过将请求参数提取到Map并简单地传递，但google checkout java sdk在请求和响应对象上明确地工作，因此在这个问题上不使用sdk会很麻烦。

到目前为止，通过HttpRequest是不是不赞成？如果是这样，是否应该有前端逻辑来处理这个问题？或者这是一种毫无根据的担忧，我不应该这么想？

Answer 1

将HttpRequest和HttpResponse包装在实现接口的类中，并使服务层依赖于接口。对于Google以外的其他服务，您可以使用请求参数传递地图，并为Google提供包装器实施。无论如何，服务层不会知道背后是什么。

Answer 2

不应将

HttpServletRequest传递给服务层。

如果您明确需要请求，则可以将逻辑放在Web层中。或者扩展库并允许它采用Map个参数（如果可能）

Answer 3

没有理由不跨多个图层跨越商务模块。把它视为例如UML调用子系统。因此，您的 CommerceSBS 包含多个组件，例如：

1. CommerceRequestMgr;控制与PSP的对话（生成到PSP和回调链接的链接）
2. CommerceCallback;也许是一个等待PSP回调的监听器servlet
3. CommerceService;实现后端逻辑，例如，数据库或ERP访问

这就是我过去所做的......

Answer 4

我同意Bozho和Boris的观点，即服务层不应该知道＆＃34;关于HttpR *。

另一种需要考虑的方法是使用适配器（位于外部服务和SL之间）。这使您可以保持SL不受欢迎的依赖关系，但适配器使您可以在必要时灵活地与外部系统集成;并且因为适配器是隔离的，只有一个特定的工作要做，所以它将是一个灵活的低风险选项。