さまざまなリクエストを受け取る SOAP-Webservice を実装しています。Manager クラスは、実装クラスに委譲する前に、この Request オブジェクトを内部表現に変換する必要がありますか?
デカップリングに関しては、これは良い考えだと思います。ただし、これを行うには、各 RequestObject クラスのコピーを作成し、元の Request と同じデータを格納する InternalRequestObject という名前を付ける必要があります。
これは理にかなっていますか？
1 に答える
1
ビジネス層 と呼ぶ実装クラスを再利用するつもりなら、それは理にかなっています。
現在の設定では、ビジネス レイヤーが Web サービスとして公開されています。Web サービスのスケルトンは、ビジネス層のクライアントです。
ここで発生する問題は次のとおりです。ビジネス層は、どのような種類のクライアントを持つかを気にする必要がありますか? ビジネス レイヤーのデータ コントラクトはクライアントによって指示されるべきですか、それともクライアントはビジネス レイヤーによって公開されたデータ コントラクトを尊重する必要がありますか?
明らかな応答は、クライアントがビジネス層のデータ コントラクトを尊重する必要があるということです。そのため、質問に対する答えは次のようになります。はい、SOAP 要求を実装クラスで使用される内部要求タイプにマップして、より適切なデカップリングを取得する必要があります。ふたつの間に。
リクエスト タイプをビジネス レイヤーに至るまで直接使用することを検討するケースが 1 つだけあります。それは、ビジネス レイヤーを SOAP 以外のものとして公開する必要がないと完全に (101%) 確信できる場合です。ウェブサービス。
アイデアは、これには2つの主要なオプションしかないということです:
1. どこでも同じリクエスト タイプを維持します。これの欠点は、ある時点で他の (SOAP 以外の) クライアントを追加する必要がある場合に、ビジネス レイヤーを介して多くの書き換えが発生することです。
また
2. SOAP 要求タイプを内部タイプにマップします。これの欠点は、コードを複製して余分な作業を行うリスクがあり、最終的にすべてが無駄であり、結局他のクライアントを追加する必要がないことを発見することです。
状況を考えて慎重に選びましょう！しかし、個人的には、これまでのところ2番の欠点に遭遇したことはありません. 私は常に新しいクライアントを追加することになりましたが、その時点で、最初からタイプをマッピングするのに役立ちました.
于 2011-05-31T21:00:45.813 に答える