Visual Studioソリューションを構築するとき、さまざまなコンポーネントが異なるプロジェクトに含まれるように構築する傾向があります(ほとんどの人がそうすると思いますが)、ユーザー定義の例外がたくさんある傾向があります。
問題は、これらの例外を(たとえば)モデルクラスとは別のプロジェクトに含める必要があるかどうかです。
私はそれらをモデルのサブ名前空間に配置し、モデルプロジェクト内のディレクトリに整理する傾向があります。しかし、それらはすべて一緒に別のプロジェクトに含まれるべきですか?
Visual Studioソリューションを構築するとき、さまざまなコンポーネントが異なるプロジェクトに含まれるように構築する傾向があります(ほとんどの人がそうすると思いますが)、ユーザー定義の例外がたくさんある傾向があります。
問題は、これらの例外を(たとえば)モデルクラスとは別のプロジェクトに含める必要があるかどうかです。
私はそれらをモデルのサブ名前空間に配置し、モデルプロジェクト内のディレクトリに整理する傾向があります。しかし、それらはすべて一緒に別のプロジェクトに含まれるべきですか?
それらがどのように使用されると想像するか、およびアプリケーションをどのようにデプロイするかによって異なります。経験則として、必要以上のパッケージ/アセンブリを作成しないでください。
例外とインターフェイス クラスを独自のアセンブリに配置する強力なケースが 1 つあります。それは、必ずしも「フル」パッケージにする必要がないクライアント間で共有する必要がある場合です。1 つの一般的なシナリオは、プラグイン アーキテクチャを構築する場合です。
それらがどのように使用されるかによって、私は推測します。例外が 1 つのプロジェクトに限定されている場合は、そこに置きます。複数のプロジェクトで使用する場合は、別のプロジェクトに配置してください。
メッセージ文字列が構成可能 (プロパティ ファイル/xml) である限り、私は気にしません。ただし、例外が複数のプロジェクトにまたがる場合は、汎用のトップ レベル インターフェイスがあれば確実に役立ちます。