4

現在、プロジェクトがあり、そのサイズは毎日増加しています。私が提供しているAPIのコンテナです。

私は現在、すべてのクラスとすべてのインターフェースをルートに持っています。

Enums、Contants などを独自のフォルダーに分離しましたが、名前空間の一部としてフォルダーを継承しません。それらは、それらを整理するための単なるコンテナーです。

誰かがここで経験を持っているかどうか疑問に思っていましたか？

インターフェイスも独自のフォルダーに分離する必要があります (名前空間の一部としてフォルダーを継承しないでください)

クラスも分けるべきですか？

他のクラスの子であるクラスもあります..つまり、クラスはそれをプロパティとして実装します。したがって、外部でインスタンス化されることはありません。したがって、それらをさらに分離して、(たとえば)「Products」というフォルダーを配置する必要があります。このフォルダー内に、Product クラス、次に item クラス、および Product に固有の他のクラスを配置しますか?

繰り返しますが、名前空間の一部としてフォルダー名を分離し、継承しない手段としてフォルダーを使用します。

フィードバックをお待ちしております。

ありがとう

4

1 に答える 1

2

この種の状況は、開発中にめったに発生しません。実際には、ほとんどの場合、多数のフォルダーを含む単一のプロジェクトではなく、個別のプロジェクトを作成することになります。個人的には、複雑なプロジェクトは明らかなコード臭だと考えています。個別のプロジェクトは並行してコンパイルできます (多かれ少なかれ、すべて依存関係の影響を受けます)。

とはいえ、本当にすべてを 1 つのプロジェクトにまとめたい場合は、次のようにします。

  • プロジェクトのすべての要素に共通するもの (便利な拡張メソッドなど) がある場合は、 という名前のフォルダーを作成し、Infrastructureそれが名前空間プロバイダーではないことを確認して、すべての共通のものをそこに置きます。
  • プロジェクトの残りの部分は、タイプではなく動作に基づいて分離しようとしています。たとえば、列挙型とクラスを分離することをお勧めしますが、それは私には間違っているように思えます-クラスまたは列挙型のデータベースエンティティがある場合、両方の列挙型を含むという名前のフォルダーEntities(したがっての名前空間) が必要です。MyProject.Entitiesクラスを 1 つの場所に配置します。(また、これを という名前のプロジェクトに突然移行した場合MyProject.Entities、名前空間を変更する必要がないことに注意してください。)

要約すると、タイプ別ではなく、機能別にファイルをグループ化してみてください。

于 2011-03-28T11:54:21.600 に答える