サービス層にHttpRequestとHttpResponseを渡すことについての考え方？

Question

私は、Orderize処理機能をサポートするCommerceServiceモジュールを持っています。これには、Authorize.net、Paypal、Google Checkoutなどのプロバイダによる支払い承認などが含まれます。 placeOrder（Order）のような単純なインターフェイスを提供し、重い作業をします。

PaypalとGoogleはリモートペイメントサービスを提供していますが、PaypalとGoogleはリモートペイメントサービスを提供しています。たとえば、ユーザーはサイトから離れることができ、ペイパルは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コールバックを待つリスナーサーブレット
3. CommerceService;バックエンドロジックを実装します。データベースやERPへのアクセスこれは私が過去にやったことある

...私はサービス層は、* HTTPRについて「知っている」べきではないとBozhoとボリスに同意

Answer 4

。

もう1つのアプローチは、アダプタ（外部サービスとSLの間に座っている）を置くことです。これにより、望ましくない依存関係をSLに残さないようにすることができますが、アダプターは必要に応じて外部システムとうまく統合できる柔軟性を提供します。アダプタは分離されており、実行する特定のジョブが1つしかないため、柔軟性の低い低リスクのオプションになります。