1

さて、私はクラスの1つをルートフォルダに入れようとしています。

UI
BusinessLogicDataAccessBusinessObjects インターフェイス
_
_

バケツが上手くいかないところがもう少しあるので、提案を探しています

  1. プライベートディクショナリを維持し、特定のキーに基づいてオブジェクトへのさまざまなアクセスを許可するCacheクラス

  2. イベントArgクラス？

また、プロジェクトの下で、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
（各機能サブシステムのサブディレクトリなし）

4

5 に答える 5

2

アセンブリ名を名前空間に合わせて、.NET Framework 自体をガイドラインとして使用するようにしています。フォルダー構造を駆動する名前空間構造を使用することで、コードベースの保守性が大幅に向上すると固く信じています。

たとえば、私たちが使用しているグローバル開発者フレームワークの一部であるキャッシュ プロバイダーがあります。次のような名前空間に存在します。

[会社].Core.Data.Caching

論理的にはデータ機能の下位にある他のデータ関連機能もあるため、キャッシングにはアダプター、コンバーター、ジェネレーターなどの兄弟があります。したがって、次の名前空間があると仮定しましょう。

[会社].Core.Data.Adapters
[会社].Core.Data.Converters
[会社].Core.Data.Caching
[会社].Core.Data.Generators

これらの関連する名前空間は、プロジェクト名でもある [Company].Core.Data というアセンブリに存在します。この構造に従って、ソリューション内のものを見つけることは非常に簡単になります。構造について言えば、ディスクにどのように格納されるかという話に戻ります。

プロジェクト名はルート フォルダー名です。これは、ローカル マシンの "C:\Source Control" であるソース管理フォルダーを想定しています。

C:\Source Control\Core[Company].Core.Data\
C:\Source Control\Core[Company].Core.Data\Adapters
C:\Source Control\Core[Company].Core.Data\Caching
C:\ソース管理\Core[会社].Core.Data\Converters
C:\ソース管理\Core[会社].Core.Data\Generators

したがって、階層としては、次のようになります。

[ソリューション]
--[Company].Core.Data
----[Adapters]
------(Adapters ファイル)
----[Caching]
------(Caching files)
---- [コンバーター]
------(コンバーターファイル)

すべてのプロジェクトを同じレベルに置き、サブ名前空間をフォルダーごとに変えます。このようにして、名前空間と物理構造を簡単に調整できます。難しい部分はバランスを見つけることです。多数の小さなアセンブリを持ちたくないので、通常はそれらをより高いレベルでグループ化し、最終的にサイズが大きくなりすぎる傾向にある場合、またはサブ名前空間が他の部分よりも頻繁に変更される場合にリファクタリングします。 .

私は何年も前からこれを行ってきましたが、私自身だけでなく、開発者にとっても非常に快適に使用できます。

EventArgs の質問については、通常はファイルごとに 1 つのクラスを実行するというコンセンサスに同意しますが、単一の使用法である場合は、EventArgs クラスを別のクラスに配置することを例外とします。多目的に使用するために、それらをアセンブリの最上位の論理ポイントに配置し、名前空間構造がスコープをバインドできるようにしました。

于 2008-11-23T18:07:00.610 に答える
0

私は通常、1クラス、1ファイルのルールに固執するのが好きですが、EventArgsに関しては、実際には、デリゲートまたはイベントを定義するのと同じファイルでそれらを宣言するのが好きです。そうでない限り、argsは複数のクラス階層で使用されますが、これは私にはあまり起こりません。

キャッシュに関しては、それがサポートするクラスのフォルダに入れます。

私は良い組織が好きですが、それで肛門になりすぎる可能性があります。

于 2008-11-23T14:41:05.627 に答える
0

これを行う正しい方法はありません。

プロジェクトと同様のテクノロジーを使用するいくつかのオープンソースプロジェクトをダウンロードし、それらからアイデアを引き出します。

申し訳ありませんが、C＃タグを見逃しました。優れた.NETプロジェクトの例については、こことここで説明しました。

于 2008-11-23T14:42:04.797 に答える
0

これは主に個人的な好みです。

EventArgクラスなどを配置する場所に関してBrianGenisioが言ったことに同意します。一度だけ使用する場合は、それらを使用するのと同じファイルに配置します。一般的なクラス/ファイルの場合、私は常に「一般」フォルダを持っています（とても便利です！;-)）

フォルダー構造について：2つ目は、3層で、サブシステムを分離したままにします。Win-Win！

于 2008-11-23T14:53:01.407 に答える
0

名前にコメントを付けたいだけです。ビジネスという言葉は誤用につながると思います。これを実行しましたが、ドメインロジックまたはサービスレイヤーの内容がわかりません。ドメインのような名前をお勧めします。Domain.Impl（インターフェイスをImplから分離するため）、次にサービス...そしてORMを使用している場合は永続性...異なるアプローチを使用している場合は異なる場合がありますが、正直なところ、BusinessLogic、DataAccessという名前について混乱しています、およびBusinessObjects。何が何なのかわかりません。BusinessObjectsには、論理的なビジネスロジックが含まれている必要がありますか？それとも単なるDTOですか？では、なぜそれらはDataAccessとは別のプロジェクトにあるのでしょうか。

于 2008-11-23T14:53:55.537 に答える