問題タブ [chain-of-responsibility]

私のプロジェクトには、Web サービスを構築する必要があるという要件があります。この Web サービスは、次のことを行います。

1. XML 形式のデータを受け入れる
2. XML 形式のデータを返す
3. XML 入力データには、ログイン情報を持つ要素と、処理が必要な別の要素データがあります。

今、私は Web サービス コードをきれいにきれいに見せることができるデザイン パターンを探しています。Webサービスは、次のような多くのことを行う必要があるためです。

1. 最初にxmlを解析します
2. ユーザー名とパスワードを確認してリクエストを認証する
3. データからオブジェクトを作成し、データをデータベースに保存します
4. クライアントに返されるxmlを準備してください。

そのため、.asmx.cs ファイルにすべてを書き込むと、コードが見苦しく見えるようになる 4 つの主要な手順があります。

近い将来、コードを簡単に保守できるように、これに適した設計パターンを誰かが提案できる場合。

このモジュールは既存のプロジェクトに統合されるため、サードパーティのモジュールや dll を使用できないなど、いくつかの制限があります。

だから私は、単一の責任の原則、責任の連鎖、コマンドまたはデコレーターパターン、または適合する他のおっとコンセプトのようなものを探していました。

検索しましたが、どの方法から始めればよいかわかりません。

ありがとう。

M.

販売注文を処理するソリューションを構築する必要があります。処理は連続して行われます。各ステップは特定のタスクを処理します。クライアントに信用があるかどうか、必要なアイテムの在庫があるかどうかなどを確認します。

責任パターンの連鎖を使用することを考えました。

私はこの古いが非常に貴重な記事を見つけました。CoR と Template パターンを比較することから始めます。結合については気にしていないので、どちらも機能しているようです。

注意すべき欠点 (または落とし穴など) はありますか?

誰かがこれらのパターンで私の頭の中の混乱を解消してください:

• 指揮系統
• 責任の連鎖

私は、両方が同じであるサイト (責任の連鎖と同じであるコマンド チェーンの例) とそうでないサイトを見てきました。

これは私がそれぞれについて理解していることです：

指揮系統：

クラスは、同じインターフェースを実装するクラスのインスタンスである「コマンド」のリストを保持するプロパティを持つ CommandChain と呼びましょう。それらはすべて onCommand(command, arguments) を実装する必要があるとします。

CommandChain には、その中に新しいコマンドを登録するための addCommand() メソッドと、コマンド名とそのパラメーターを受け入れる runCommand() があります。このメソッドは、コマンドの 1 つが応答し、対応するアクションを実行し、ok を送信するまで、コマンドのリストをループする必要があります。

責任の連鎖

一部のサイトで見たように、これはほとんど同じですが、次の違いがあります。クラスにループするコマンドのリストを格納する代わりに、各コマンド インスタンスは次のコマンド インスタンスへの参照を格納します。

では、この違いは、両方の設計パターンが異なると考えるのに十分な大きさですか?

それらは実際にどのような場合に適用されますか？

私は一連の責任パターンを実装しようとしていますが、具象クラスでは setnexthandler が次を設定していないが常に同じであるため、何かが欠けているようです。私の間違いは、else statems next.setNextHandler(next); の processMalfunction() メソッドの具象クラスにあると思います。最初のものは next.setNextHandler(Severity.Medium) にすべきだと思います。だから、あなたが見てみることができるなら、ここにコードがあります。これがコードです。

リクエストを変更する必要がある複数のノードがある場合、「責任の連鎖」設計パターンを引き続き利用することは良い考えですか? それとも、このパターンは、1 つの (不明な) ノードのみが要求を排他的に処理する場合にのみ使用する必要がありますか?

IE: ノード 2 とノード 3 の両方が要求 (R) に影響を与える必要があります。したがって、ノード 2 がリクエストを処理しても、引き続きリクエストをリストに沿って次のハンドラーに渡したいと考えています。

私のアプリケーションでは、特定の一連の手順で DB からデータをロードする必要があります。たとえば、すべての顧客をロードしてから、すべての注文をロードして製品をロードするなどです。ただし、1 つまたは 2 つのケースでは、順序が異なり、ロードする必要もあります。追加データ。

私の最初の考えは、顧客、注文、または製品の実際のロードにコマンド パターン (ロード コマンド メソッドを使用) を使用し、一連の責任を使用してコマンドを結び付けることができないかということです。これは良いアプローチですか、それとも私はここで物事を設計しすぎていますか?

サンプルコードは非常に役に立ちます。提案をありがとう

デザインパターンを勉強しています。C++で責任の連鎖パターンを実装する方法がわかりません。Argoツールを使用して、ダイアグラムからコードを生成しています。

この図では、Oracleクラスは「クライアント」です。Oracle.cppコンストラクタメソッドには次の行があります

ここで、「エラー：'検証'はこのスコープで宣言されていません」というメッセージが表示されます。私の質問：Oracleから検証へのUML関係「依存関係」を作成する必要がありますか？または、どうすればこのエラーを修正できますか？

Chain of Responsibility パターンの概念は理解していますが、間違って使用している可能性があります。

いくつかの種類の製品があり、これらの種類の製品ごとに表示されるインターフェイスを制御するコントローラーがあります。ユーザーが製品のタイプを選択すると、各コントローラーが適切なインターフェイスを表示して操作します。

このために、私は大丈夫とは思えない一連の責任パターンを使用しています。私がやっていることは、コントローラーのチェーンを作成することです。製品タイプのリクエストを受け取るとすぐに、それをコントローラーのチェーンに渡し、適切なコントローラーにリクエストを実装させます。

しかし、考えてみると、単純なファクトリを使用して同じことを実現できましたが、多くの条件文が含まれていました。

この状況での責任の連鎖の使用についてどう思いますか?

パイプラインに一連の責任設計パターンを使用しています。私が発見した問題の 1 つは、チェーンを追加するにつれて、構成オブジェクトがどんどん大きくなることです。基本的に、私の構成オブジェクトは巨大なシングルトンになっています。この状況を処理する効果的な方法はありますか?

詳細：

私の現在のセットアップは

構成オブジェクトをチェーンに渡すことでチェーンを使用します。

構成オブジェクトには、ハンドラーに必要なすべての構成情報が含まれているため、チェーンを追加すると、ますます大きくなります。

考えられる解決策:

この投稿での最良の答えは、依存性注入を使用することです。

構成設定の問題に適用できる設計パターンはどれですか?

ただし、設計を大幅に変更せずに、一連の責任設計で依存性注入を使用する方法がわかりません。

誰かがこの問題について私を助けてくれますか? ありがとう！