クラスバケット。 。
https://stackoverflow.com/questions/312565
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
わかりました。だから、私はクラスのいずれかをルートフォルダーに入れようとしました：
UI
BusinessLogic
DataAccess
BusinessObjects
インターフェース
私はバケツが上手く見えない場所がいくつかあるので、提案を探しています
-
プライベート辞書を維持し、特定のキーに基づいてオブジェクトへのさまざまなアクセスを許可するキャッシュクラス
-
イベント引数クラス？
また、プロジェクトの下で、3つすべて（データアクセス、ビジネスオブジェクト、busiensslogic）を持つサブシステムを持つようになりました。フォルダ構造を分割するにはどうすればよいですか？
A。
ProjectX
--Subsystem1
---- BusinessObjects
---- DataAccess
---- BusinessObjects
--Subsystem2
---- BusinessObjects
---- DataAccess
---- BusinessObjects
または
ProjectX
--BusienssLogic
---- Subsystem1BL
---- Subsystem2BL
--DataAccess
---- Subsystem1DA
---- Subsystem2DA
--BusinessObjects
---- Subsystem1BO
---- Subsystem2BO
または
ProjectX
--BusinessLogic
--DataAccess
--BusinessObjects
（機能サブシステムごとにサブディレクトリなし）
解決
アセンブリ名を名前空間に合わせて、.NET Framework自体をガイドラインとして使用しようとしています。フォルダー構造を駆動する名前空間構造を使用すると、コードベースのメンテナンス性がはるかに向上すると確信しています。
たとえば、私たちが使用するグローバル開発者フレームワークの一部であるキャッシングプロバイダーがあります。次のような名前空間に存在します：
[Company] .Core.Data.Caching
他のデータ関連機能も論理的にデータ機能の下にあるため、キャッシングにはアダプター、コンバーター、ジェネレーターなどの兄弟があります。したがって、次の名前空間があると仮定しましょう：
[Company] .Core.Data.Adapters
[会社] .Core.Data.Converters
[会社] .Core.Data.Caching
[会社] .Core.Data.Generators
これらの関連する名前空間は、プロジェクト名でもある[Company] .Core.Dataと呼ばれるアセンブリに存在します。ソリューションで物を見つけることは、この構造に従って非常に簡単になります。構造について言えば、ディスクへの格納方法に戻ります。
プロジェクト名はルートフォルダー名です。これは、＆quot; C：\ Source Control＆quot;というソース管理フォルダーを想定しています。私のローカルマシンで：
C：\ Source Control \ Core [Company] .Core.Data \
C：\ Source Control \ Core [Company] .Core.Data \ Adapters
C：\ Source Control \ Core [Company] .Core.Data \ Caching
C：\ Source Control \ Core [Company] .Core.Data \ Converters
C：\ Source Control \ Core [Company] .Core.Data \ Generators
つまり、階層としては、次のようになります：
[ソリューション]
-[会社] .Core.Data
---- [アダプタ]
------（アダプタファイル）
---- [キャッシュ]
------（キャッシュファイル）
---- [コンバータ]
------（コンバーターファイル）
すべてのプロジェクトを同じレベルに配置し、サブ名前空間をフォルダーごとに変更します。これにより、名前空間と物理構造を簡単に調整できます。難しいのはバランスを見つけることです。多数の小さなアセンブリが必要ないため、通常はより高いレベルでグループ化し、大きくなりすぎる傾向がある場合、またはサブ名前空間が他の部分よりも頻繁に変更される場合に最終的にリファクタリングします。
私はこれを何年もやっていますが、自分だけでなく、開発者にとっても非常に快適です。
EventArgsの質問に関しては、通常、ファイルごとに1つのクラスを行うというコンセンサスに同意しますが、EventArgsクラスを別のクラスと一緒に配置することは例外です。多目的の場合、名前空間構造がスコープをバインドできるように、アセンブリ内の最も高い論理ポイントに配置します。
他のヒント
通常、1クラス、1ファイルルールに固執するのが好きですが、EventArgsに関しては、デリゲートまたはイベントを定義するのと同じファイルで実際に宣言するのが好きです。 argが複数のクラス階層で使用されている場合を除き、これは頻繁に発生することはありません。
キャッシュについては、サポートするクラスのフォルダーに入れます。
良い組織が好きなのと同じように、人はあまりにもアナルになりがちです。
これは主に個人的な好みです。
ブライアン・ジェニシオ言った EventArgクラスの配置場所などについて同意します。それらを一度使用し、それらを使用する同じファイルに入れてください。一般クラス/ファイルの場合、私は常に「一般」フォルダを持っています（なんと便利！;-））
フォルダ構造について：2番目のフォルダに移動します。1つは3層であり、サブシステムを分離したままにします。 Win-Win！
名前にコメントを追加したいだけです。 ビジネスという言葉は誤用につながると感じています。私たちはこれを行いましたが、今ではそれが何であるかわかりません：ドメインロジックまたはサービスレイヤー。 私は次のような名前を提案します ドメイン。 Domain.Impl（Implからインターフェイスを分離するため） そして、サービス...そしておそらくORMを使用している場合は永続性...異なるアプローチを使用している場合は異なるかもしれませんが、正直に言うと、BusinessLogic、DataAccess、およびBusinessObjectsという名前について混乱しています。 何が何なのか分かりません。 BusinessObjectsにはビジネスロジックを含める必要がありますか？それとも単にDTOですか？では、なぜDataAccessとは別のプロジェクトにあるのですか？
