このパターンに関するいくつかの質問を見てきましたが、この設計パターンについてもっと深く理解しようとしています。この点に関するリソース、このパターンを使用する傾向があるシナリオと避けるべきシナリオに関する専門家の解説、およびいくつかの実例は、この点で非常に役立ちます。私はCORタイプが何であるかを探しているのではなく、専門家からの高度な解説を探しています. これは、次回このパターンをより責任を持って適用するのに大いに役立ちます。
1 に答える
2
わかりました、つい最近、実際のエンタープライズ開発でこのパターンを使用した経験があります。
私たちのシステムでは、ベース、製品固有、およびユーザー固有のさまざまなレベルのストレージがありました (優先順位に従って)。各ストレージには、Web ページに表示される要素をメタ言語で記述した XML ファイルのセットが保持されていました。各 XML ファイルには、表示されるページ全体が記述されています。
ユーザーが Web ページに移動しようとすると、システムはページ ID に関して必要な XML ファイルのストレージでルックアップを実行しました。
必要なファイルが見つかったときにルックアップが終了しました。マージ アルゴリズムは予期されませんでした (レイヤー間のマージはまったく行われませんでした)。
したがって、この特定の状況のために、1 つのメソッドを持つインターフェースを (疑似コードで) 導入しました。
ViewMetadata GetViewMetadata(string viewId);
このインターフェースの実装者であるストレージのチェーンを構築しただけです。XML ビュー メタデータから実際の HTML 表現を構築する役割を担っていた HttpHandler (Asp.Net ユースケースの場合) には、ルックアップ メカニズムへ のエントリ ポイントが 1 つしかありませんでした: 前述のインターフェイス実装者のインスタンスです。
すべて問題ないように見えました (実際には数か月間)。しかし
新しい要件が来ました。この要件は「プロモーション」に関するものでした。特定の状況 (「プロモーション ワークフロー」) での XML ファイルは、ユーザー ストレージから製品ストレージに転送する必要があります。
実際には、ルックアップ メカニズムの実装が抽象的すぎるため、この要件を処理できませんでした。ストレージのチェーン全体へのハンドラーの抽象的なエントリ ポイントは 1 つしかありませんでした。
そのため、この要件の CoR パターンを却下しました。現在、実際のハンドラーは 3 つすべてのストレージへの明示的な参照を持ち、「wiew Id = X でビューを昇格」要求が来ると、ユーザー ストレージから直接メタデータを取得し、メタデータを製品ストレージに保存します。
したがって、結論として、チェーン要素との明示的な相互作用についていくつかの要件がある場合、CoR パターンは優れたソリューションではないと言えます。CoR "HandleRequest()" のインターフェースが抽象的すぎると、チェーンのエントリ ポイントと対話する機会しか得られません。
ところで、これは CoR ベースの実装を保存する機会でしたが、問題は実際には努力と保守性に関するものでした :)
于 2010-12-11T23:11:48.297 に答える