15

まず、名前空間がフォルダー構造と一致する必要があり、各言語アーティファクトが独自のファイルにある必要があることに同意しましょう。

(ソリューション内のフォルダーは名前空間と一致する必要がありますか?を参照してください)。

次の問題は、ディスク上でフォルダを実際にどのように編成するかです。
ABC 名前空間に ClassC があり、ABCD 名前空間に ClassD があるとします。
また、各名前空間が独自のアセンブリ (プロジェクト) に組み込まれており、受け入れられているベスト プラクティスに従って名前空間が右から左への依存関係を持っていると仮定します (ABCD は、A に依存できる AB に依存できる ABC に依存できます)。各名前空間が個別のアセンブリにある必要はないことを理解していますが、一般的に、いくつかの名前空間は個別のアセンブリにあり、私の例はそれを示しています。

フォルダー ツリーを作成するには、(少なくとも) 2 つの方法があります。これを「ネストされたフォルダー」と「フラット フォルダー」と呼びます。

1 - ネストされたフォルダー:

A
--A.csproj --B ----ABcsproj
---- C ------ABCcsproj ------classC.cs ------D -------- ABCDcsproj --------classD.cs






また

2 – フラット フォルダ:

A
--A.csproj
AB
--ABcsproj
ABC
--ABCcsproj
--classC.cs
ABCD
--ABCDcsproj
--classD.cs

すでにいくつかの仮定を行っていることがわかります。

  • 各プロジェクト ファイルには、名前空間に基づく完全修飾名 (FQN) があります。
  • 各クラス ファイルは非 FQN を使用します

入れ子になったフォルダーはより自然に見えます (私たちは皆、階層が好きです) が、大規模なソリューションではナビゲートするのが少し難しいかもしれません:

VS でソリューションを見ると、ネストされたビューではなく、プロジェクトのフラット リストが表示されます。これは「フラット フォルダー」に似ているため、VS のビューに合わせてディスク上のフォルダーを編成するメリットがあるかもしれません。

ディスク上の各フォルダーを見ると、そのプロジェクトのフォルダー アーティファクトと名前空間のサブフォルダーが表示されます。例として C を取り上げます。

C
--bin
--D
--obj
--Properties
--ABCcsproj
--classC.cs

D の本名によっては、D が C 名前空間の組織フォルダーではなく、名前空間フォルダーであることが明らかでない場合があります。

.NET (8 ～ 9 年前) とそれ以前の Java では、初日からフォルダーと名前空間があったことは知っていますが、個人的に言えば、大規模なプロジェクト組織のベスト プラクティスについて合意に達していないようです。ソリューション。皆さんの考えを知りたいです。

ありがとう
マイケル

4

8 に答える 8

8

私はフラットアプローチを使用しています。ネストされた階層を維持するのは難しすぎると思います。最大限の再利用性と相互参照を念頭に置いて、プロジェクトをいくつかのソリューションにグループ化しましたが、常にこれで満足できると感じました。例 (プロジェクトはインデントされています):

CompanyName
  CompanyName.Core
    Class1
    Struct2
    Enum3
  CompanyName.Data
  CompanyName.Web

CompanyName.Projects
  CompanyName.Projects.Core

CompanyName.Projects.ProjectX
  CompanyName.Projects.ProjectX.Core
  CompanyName.Projects.ProjectX.Website
  CompanyName.Projects.ProjectX.ToolY

などなど

編集：ナンセンスな発言を削除

于 2008-12-31T10:01:16.730 に答える
5

私はネストされたプロジェクトの大ファンではありません.プロジェクトを構造の奥深くに埋めてしまい、そのプロジェクトを別のアプリケーションで再利用する必要がある場合は、コードをコピーして貼り付けますか? 私はいくぶんフラットな構造に従うのが好きですが、名前空間によって編成されています。

これは私がそれを行う方法です：

- DataHelpers\
---Factory\
---DataAccess\
---...
- Components\
--- EmailProcessor\
--- ErrorLogger\
- Desktop\
--- WindowsApp1\
- Services\
--- WindowsService1\
--- WindowsService2\
- WebApps\
--- WebApp1\
--- WebApp2\

今、私が持っている各主要なアプリケーションの中で、例えば：

- WindowsService1\
--- WindowsService1\ (this contains all *.cs, bin, obj, etc and .csproj file)
--- Solution\ (this contains the .sln file where you link to other projects like ErrorLogger, etc)

それが理にかなっていることを願っています！

于 2008-12-30T18:13:36.660 に答える
4

「まず、名前空間がフォルダー構造と一致する必要があり、各言語アーティファクト [sic] が独自のファイルにある必要があることに同意しましょう。」

面白いことに、これが Java でのパッケージのしくみです。名前空間とディレクトリ構造の間のリンクを解除することは、C# が導入した改善の 1 つと考えられていました。そうではありませんか？(私の無知を許してください、私は Java の人です。)

于 2008-12-30T17:46:43.360 に答える
3

私は常にネストされた階層を行ってきました。これにより、新しいプロジェクトを既存のソリューションに追加する場所が非常に明確になり、名前空間がディスク上で適切に整理されます。また、名前空間とプロジェクトの区別がより明確になります。

于 2008-12-30T17:57:01.670 に答える
2

ネストされたプロジェクトを使用すると、WindowsのMaxPathの問題が発生するリスクがあります。これは、ネストされた構造を使用するための大きな問題です。MaxPathにヒットしないように、VSプロジェクトに3文字の頭字語で名前を付ける必要がある、開発プロジェクトの途中でこの小さなGemに会うことを想像してみてください。アセンブリの名前のインスピレーションとして終わるMSのバグ。なんて冗談でしょう。平らな構造での作業は、全体的にはるかに優れています。

   -SouceControlFolderName
     -Project1
       -Src
         -Main
           -Company.Project1.AppName
             *Company.Project1.AppName.sln
             *Company.Project1.AppName.Tests.sln
             -Company.Project1.AppName.Common
             -Company.Project1.AppName.Common.Tests
             -Company.Project1.AppName.Entities
             -Company.Project1.AppName.Entities.Tests
             -Company.Project1.AppName.Security
             -Company.Project1.AppName.Security.Tests
             -etc.

テストプロジェクト用に別のディレクトリを作成するか、上記のようにそれらをすべてまとめて、ソース管理、つまりSubversionに追加するときに管理しやすくすることができます（TFSは、VS統合だけでなくExplorer統合が必要であるという事実を除けば、多くの点で優れています。適切なオフラインストーリー）

于 2011-02-02T17:24:10.777 に答える
0

フラットなアプローチが機能しなくなるカットオフポイントを定義する必要があると思います。たとえば、小規模なプロジェクトに典型的な 3 層アーキテクチャがある場合、外部レベルに 3 つのプロジェクトがあっても問題ありません。ただし、数十個ある場合は、ある種のグループ化が機能のセグメント化に役立ち、ソリューション全体がより理解しやすくなります。

于 2008-12-31T10:05:07.707 に答える