C＃プロジェクトヘルパーまたはユーティリティクラスの整理
.NETプロジェクトでヘルパークラスを配置する必要がある場合のベストプラクティスは何ですか？ビジネスレイヤーのものとは別のクラスを参照しますが、appSetting構成マネージャーや、モジュール固有の場合やアプリ全体で使用される場合があるその他のコードなどのプレゼンテーションやアプリのもの。
私はいつもこのようなことをかなり流動的にすることを許可します。それは言った：
- 「ヘルパー」クラスは他のクラスと同じようにテストします。これにより、静的ではなくなる傾向があります。
- 必要に応じて、これらのヘルパーを個別のメソッドとして作成することから始めることができます。それらは複数のクラスで必要であることがわかったので、同じプロジェクト内の独自のクラスまたは「ユーティリティ」クラスに移動します。
- それらが複数のプロジェクトで必要であることがわかった場合は、「階層」の上位に移動します。プロジェクトからソリューションへ、ソリューションからサブシステムへ、サブシステムからアプリケーションへ、アプリケーションからライブラリまたはフレームワークへなどです。
私はRandolphoとBenが行うことを組み合わせて行う傾向があります。Utilities名前空間の「Utilities」フォルダーで静的ヘルパークラスを使用します。ファイル編成が改善され、アプリケーションの名前空間の残りの部分が明確に保たれます。
ほとんどの場合、ソリューションにはMyProject.Coreクラスライブラリがあり、そのようなものを配置します。
編集：私は「より大きな」質問に答えたかもしれません。
単一のプロジェクトでは、それはすべてプロジェクトのサイズに依存します。 Microsoft設計ガイドラインでは、名前空間のタイプが5つ未満（この数が間違っている場合は訂正してください）の場合は、名前空間を作成しないでくださいと説明されています。
このようなクラスは、たとえばヘルパーがいくつかのビジネスオブジェクトまたはコアオブジェクトを使用する必要がある場合を除いて、それを必要とするすべてのプロジェクトによって参照されることを目的としたCommonというアセンブリに配置されます。
私たちのほとんどは、それらを「ヘルパー」フォルダに入れるだけです。
ヘルパーによっては、必要に応じてモックできるように、メソッドを仮想としてマークすることをお勧めします。それまたはそれが実装するインターフェースにバインドしますが、インターフェースごとに1つの具象しかない場合は、やり過ぎかもしれません。
ヘルパーメソッドが外部依存のない純粋な計算でない限り、いかなる状況でも静的であってはなりません。
それでも、再考してください。
私はそれらをutils名前空間に入れる傾向があります。それらがかなり一般的である場合は、mainproject名前空間のいずれか。 MyProject.Utils.MyHelperClass、またはそれらがより具体的である場合は、サブ名前空間MyProject.CRM.Utils.MyCRMHelperClass。