27

.NETプロジェクトでヘルパークラスを配置する必要がある場合のベストプラクティスは何ですか？ビジネスレイヤーのものとは別のクラスを参照しますが、appSetting構成マネージャーや、モジュール固有の場合やアプリ全体で使用される場合があるその他のコードなどのプレゼンテーションやアプリのもの。

4

6 に答える 6

23

私は常に、このようなことをかなり流動的にすることを許可しています。それは言った：

  1. 「ヘルパー」クラスを他のクラスと同じようにテストします。これにより、静的ではない傾向があります。
  2. 必要に応じて、これらのヘルパーを個別のメソッドとして作成することから始めます。それらが複数のクラスで必要であることがわかったので、それらを独自のクラスまたは同じプロジェクトの「ユーティリティ」クラスに移動します。
  3. それらが複数のプロジェクトで必要であることがわかった場合は、プロジェクトからソリューション、ソリューションからサブシステム、サブシステムからアプリケーション、アプリケーションからライブラリまたはフレームワークなど、「階層」の上位に移動します。
于 2010-07-29T19:42:48.993 に答える
2

ほとんどの場合、ソリューションにはMyProject.Coreクラスライブラリがあり、そのようなものを配置します。

編集：私は「より大きな」質問に答えたかもしれません。

単一のプロジェクトでは、それはすべてプロジェクトのサイズに依存します。Microsoftの設計ガイドラインでは、名前空間のタイプが5つ未満（この数が間違っている場合は訂正してください）の場合は、名前空間を作成しないでくださいと説明されています。

于 2010-07-29T19:10:58.030 に答える
2

私は、Randolpho と Ben が行っていることを組み合わせて行う傾向があります。Utilities 名前空間の「Utilities」フォルダーにある静的ヘルパー クラスを使用します。ファイル編成が改善され、アプリケーションの名前空間の残りが明確に保たれます。

于 2010-07-29T19:57:06.043 に答える
1

私たちのほとんどは、それらを「ヘルパー」フォルダに入れるだけです。

ヘルパーによっては、必要に応じてモックできるように、メソッドを仮想としてマークすることをお勧めします。それまたはそれが実装するインターフェースにバインドしますが、インターフェースごとに1つの具象しかない場合、それはやり過ぎかもしれません。

ヘルパーメソッドが外部依存のない純粋な計算でない限り、いかなる状況でも静的であってはなりません。

それでも、再考してください。

于 2010-07-29T19:10:14.357 に答える
1

私はそれらをutils名前空間に入れる傾向があります。それらがかなり一般的である場合はメインプロジェクトの名前空間で、たとえばMyProject.Utils.MyHelperClass、より具体的である場合はサブ名前空間MyProject.CRM.Utils.MyCRMHelperClassで。

于 2010-07-29T19:10:54.077 に答える
1

Commonこのようなクラスは、ヘルパーがいくつかのビジネス オブジェクトまたはコア オブジェクトを使用する必要がある場合を除いて、それを必要とするすべてのプロジェクトによって参照されることを意図した、たとえば呼び出されるアセンブリに配置されます。

于 2010-07-29T19:37:33.397 に答える