答えはもちろん「依存する」ですが、あなたのユースケースを考えると、私はノーと言うでしょう。理由は次のとおりです。
C＃はすばらしいです-それをスクラッチして、最高の-オブジェクト指向言語です。実際、とても良いので、単純なプロジェクトとして始まったものについて、狂信的に純粋なビジョンを実装しようとすることに巻き込まれることがあります。JavaScriptやObjective-CやPHPのコードを書くときは、そんなことはあまりありません。
私がこの「モード」、この種の麻痺に入るとき、症状の1つは例外処理とジェネリックとメタプログラミングへの執着かもしれません。3つすべてが一緒になることもあります。新しい、比較的未知の、または粗末な仕様と目標に取り組んでいる場合、問題になる可能性がはるかに高くなります。実装の詳細に行き詰まるのではなく、私が合理的に予想するほとんどのシナリオに対応できるものを作成しようとするのはなぜでしょうか。その後、詳細を取得するのに取り掛かると、基礎が築かれ、ずんぐりした小さなメソッドの束などが作成されます。たぶん他の誰かがUIコードで作業するでしょう、私はそれらにこれらの素晴らしいサービスとこれらの契約を提供します...
残念ながら、それはまだ私には起こりません。起こりがちなのは、私が「インフラストラクチャ」に取り組んでいるこの道から始めることです。
- 独自のIoCコンテナーインターフェイスを作成するか、他の方法でねじ込む
Castle.Windsor
- アプリケーションでタイプマッピングを処理する方法を決定する
- 例外処理を使用して、抽象メンバーへの呼び出しに類似し、その呼び出しをラップする抽象基本クラスの制御フローロジック
Interceptors を作成する
- 以下のための抽象基底クラスを作成する
IRepository、IUnitOfWork、IDomainService、ICrossCuttingValidation、など
- まさにそのような
IFrameworkExceptionメタアプローチを否定する何かのための階層的オブジェクトモデルを記述しようとすること（のような）
例外の説明があなたの好みに十分正確であるかどうかに夢中になったら、他のいくつかの重要な機能が実装されていないことを本当に否定しています。例外の性質からもわかるように、これはイベント駆動型の例外ではなく、入力方法（UIやパイプなど）から明らかに遠く離れて発生し、おそらく本質的に決定論的です-のように、ユーザーが何を入力するかを予測しますが、どのアセンブリをロードするかなどを予測できます。
ちなみに、説明が気になるなら、適切なスコープでオーバーライドする拡張メソッドを書いてみませんか？
ですから、これは本当に私に一種の抽象化と分析麻痺をあなたに投影することですが、私はそれが適切だと思います。安全面にとどまるためには、次のException場合にのみサブクラス化します。
- 一般的に処理しようとしているランタイム例外を実際に経験しました
- ランタイム例外は、設計時に合理的に除外できるものではありません
- 例外は、既存の膨大な数の
Exceptionサブクラスではまだ十分にカバーされていません
- あなたは実際にあなたが例外をどのように処理したいのか、そうでない場合はそれを考えています、それはあなたがそれを考えてそれに戻る必要があるほど複雑だからです
- あなたのアイデアは、メタデータ、そのスコープ、その内部例外などを変更するだけでなく、例外を生成する基になるオブジェクトまたはイベント、および/または実際にそれを処理する方法をより多く扱います
- あなたはすでにUIを書いている、またはUIのようなものの入力に面する側の大部分に対して責任がない