MVC に似たパターンを使用してアプリケーションを構築しています。状況は次のとおりです。関連付けられたリポジトリに変更を加えるモデルのコンテキストで。変更によって例外がスローされた場合、エラーに関する情報をユーザーに表示する正しい方法は何ですか? 私のプログラムの以前のバージョンでは、スパゲッティコード編成 (モデル、ビュー、コントローラーが重複) がある場合、ビューからほとんどすべてを行っていたため、エラーについてユーザーに通知するメッセージボックスを起動することは奇妙ではありませんでした。今、この新しいバージョンでは、私は物事を正しく行いたいので、モデル層に視覚的表現を持つことは悪いことだと思います. 少し前に、例外をキャプチャする正しい方法は何かと尋ねました。私が言及していた特定のポイントは、例外を内部コードから上位レイヤーにスケールアップするのではなく、最上位レイヤーでキャプチャすることでした。ほとんどすべての応答は、適切なアプローチではなく、責任あるエンティティによってキャプチャされ、再度スローされるというものでした。だから私は頭の中でこの矛盾を抱えています。関心の分離を維持してスケールアップすることは避けられないと考えていましたが、それは以前のアドバイスと矛盾しています。どうすれば続行できますか？しかし、それは以前のアドバイスと矛盾しています。どうすれば続行できますか？しかし、それは以前のアドバイスと矛盾しています。どうすれば続行できますか？
質問する
481 次
1 に答える
2
一般的なパターンは、既存のモデルにエラーを配置する一般的な場所を持つことです。
IEnumerable<ErrorBase>これを行う簡単な方法の 1 つは、すべてのモデル クラスを、 type のプロパティまたは選択した他の型を持つ基本モデル クラスから継承させることです。
次に、プレゼンターで、必要に応じてエラー コレクションと表示を確認できます。
例外が発生する限り、私が使用するアプローチは (作成しているアプリケーションのタイプにほとんど関係なく)、特別なログ記録 (重要なローカル変数のログ記録など) を行う場合にのみ、より低いレベルで例外を処理することです。または、その例外を除いて何か知的なことができるかどうか。それ以外の場合は、泡立ててください。
プレゼンター (または Web サービス クラスなど) の直前のレイヤーで、例外をキャプチャし、一般的なログを作成し、「サニタイズされた」例外でラップ (または置き換え) することができます。UI の場合は、機密データを公開しないようにし、可能であればわかりやすいメッセージを表示するようにします。Web サービスの場合、これらを何らかの障害に変換します。等。
最上位層は、バブルされた例外に対して「責任を負いません」。彼らは単に、それらがエンドユーザー (または Web サービスクライアントなど) に表示されないようにする責任があります。それらを... 言い換えれば、それらを適切に「提示」しています。
関心の分離は経験則として従うべきパラダイムであり、すべてを所有する布告ではないことを忘れないでください。漏れやすい抽象化と同じように、漏れやすいパラダイムがあります。意味のあることを行い、あまり心配しないでください。:)
于 2011-03-08T02:22:37.667 に答える