8

私のバックグラウンドは主に Java 開発者ですが、最近は .NET でいくつかの作業を行っています。そこで私は、.NET をうまく扱えるように、自宅でいくつかの簡単なプロジェクトを実行しようと試みてきました。Java での経験の多くを .NET (特に C#) での作業に転用できましたが、私を本当に困惑させたのは名前空間だけです。

名前空間がJavaパッケージに似ていることは知っていますが、主な違いは、Javaパッケージでは実際のファイルフォルダーを使用して分離を表示するのに対し、.NETではそうではなく、すべてのファイルが単一のフォルダーに存在することです。名前空間は各クラスで単純に宣言されます。

私はいつもパッケージを、関連するコードを整理してグループ化し、ナビゲートと理解を容易にする方法と見なしていたので、これは奇妙だと思います。.NET では、この作業はこのようには機能しないため、時間の経過とともに、プロジェクトはより過密になり、ナビゲートしにくくなります。

ここで何か不足していますか?私はそうしなければなりません。ソリューション内で物事を別々のプロジェクトに分割する必要がありますか? または、プロジェクト内でクラスとファイルを整理しておくためのより良い方法はありますか?

編集: ブレアが指摘したように、これはここで尋ねられた質問とほぼ同じです。

4

9 に答える 9

11

これがベスト プラクティスであるとは言えませんが、名前空間を反映したディレクトリ階層にファイルが編成されているのをよく見かけます。それがあなたのコードのメンタルモデルにもっと合っているなら、そうしてください - 私は何の害も考えられません。.NET モデルが名前空間、プロジェクト、およびディレクトリ構造間の関係を強制しないからといって、必要に応じてそのような関係を持つことができないわけではありません。

コードを必要以上のプロジェクトに分割することには少し不安があります。これにより、コンパイルが遅くなり、複数のアセンブリを管理する必要がある場合にオーバーヘッドが少し増える可能性があるためです。

編集:この質問は、ソリューション内のフォルダーが名前空間と一致する必要があるのとほぼ同じであることに注意してください。

于 2008-09-11T02:29:49.687 に答える
8

はい、.NET 名前空間では、ファイル システムなどに依存しません。私の意見では、それは大きな利点です。たとえば、柔軟な配布を可能にするさまざまなアセンブリにコードを分割できます。

Visual Studio で作業している場合、プロジェクト ツリーに新しいフォルダーを追加すると、IDE は新しい名前空間を導入する傾向があります。

MSDN からの便利なリンクを次に示します。

名前空間の命名ガイドライン

名前空間に名前を付けるための一般的なルールは、次のように、会社名の後にテクノロジ名とオプションで機能とデザインを使用することです。
会社名.技術名[.機能][.デザイン]

もちろん、より適切な方法で名前空間を使用できます。ただし、コードを共有する場合は、受け入れられている標準に従うことをお勧めします。

編集

.net 開発者には、フレームワーク設計ガイドラインのコピーを入手することを強くお勧めします。この本は、 .NET の設計方法と設計理由を理解するのに役立ちます。

于 2008-09-11T02:31:12.400 に答える
4

名前空間は論理的なグループであり、プロジェクトは物理的なグループです。

何でこれが大切ですか?.NET 2.0、3.0、および 3.5 について考えてみてください。.NET 3.0 は、基本的に .NET 2.0 にいくつかのアセンブリを追加したもので、3.5 にはさらにいくつかのアセンブリが追加されています。たとえば、.NET 3.5 では、DataPagerコントロールが追加されます。これは Web コントロールであり、.NET にグループ化する必要がありますSystem.Web.UI.WebControls。名前空間と物理的な場所が同じであったとしても、それは別のアセンブリにあるためではありません。

したがって、名前空間を独立した論理エンティティとして持つということは、互いに組み合わせて使用​​することを意図しているため、すべて論理的にグループ化されたいくつかの異なるアセンブリのメンバーを持つことができることを意味します。

(また、物理レイアウトと論理レイアウトがかなり似ていても問題はありません。)

于 2008-09-12T03:30:14.043 に答える
4

通常、VS ソリューションには 1 つ以上のプロジェクトが含まれます。これらのプロジェクトにはデフォルトの名前空間があります (通常、名前空間はプロジェクトの名前です)。通常、プロジェクト内にフォルダーを追加すると、その中のすべてのクラスに次のような名前が付けられます。

DefaultNamespace.FolderName.ClassName

もちろん、プロジェクトのデフォルトの名前空間を変更して、クラスに好きな名前を付けることができます。

いつ/どのようにプロジェクトに分割するかについては、経験や好みの問題です。ただし、プロジェクトを整理しておくために、ソリューション内のプロジェクトに分割する必要があります。あまりにも多くのアセンブリを管理するのが面倒になった場合 (Blair が提案したように)、いつでもアセンブリを単一のアセンブリにILMergeできます。ILMerge の優れている点は、アセンブリが 1 つだけになっても、すべてのクラスが元の完全修飾名を保持していることです。

VS ソリューションはコードとは無関係であることを覚えておくことも重要です。それらは構築されません。VS ソリューションは、プロジェクトをグループ化する方法にすぎません。ビルドされて DLL に変換されるのはプロジェクトです。

最後に、VS では、ソリューション内の任意の場所に「仮想」フォルダーを追加できます。これらのフォルダーは、ファイル システム内のフォルダーにマップされず、ソリューション内のプロジェクトやその他の成果物を整理するための別の手段として使用されます。

于 2008-09-11T02:31:07.563 に答える
3

実際、.Net 環境では、スパゲッティを壁にぶつけるように IDE/ファイルシステムにコードを投げることができます。

ただし、これは、このアプローチが正気であることを意味するものではありません。一般的には、前述の project.foldername.Class アプローチに固執することをお勧めします。また、すべてのクラスを 1 つの名前空間から同じクラスに保持することも非常に良い考えです。

Java では、このような厄介なことを行うことも、必要なすべての「柔軟性」を得ることができますが、ツールはそれを強く思いとどまらせる傾向があります。正直なところ、.Net の世界に足を踏み入れたときに私が最も混乱したことの 1 つは、比較的貧弱なガイダンスのおかげで、これがいかにずさんで一貫性がないかということでした。ただし、少し考えれば、物事を正気で整理するのは簡単です。:)

于 2008-09-11T02:37:01.417 に答える
3

違いは、.net 名前空間は Java パッケージとあまり関係がないことです。

.net 名前空間は、純粋に宣言的なスコープを管理するためのものであり、ファイル、プロジェクト、またはそれらの場所とは何の関係もありません。

その名前空間に「using」を含めると、特定の名前空間で宣言されたすべてのものにアクセスできます。

非常に簡単。

名前の選択と「.」の有無/数 使用するセパレーターは完全にあなた次第です。

VS はデフォルトで、名前空間に .foldernames を追加して、役立つようにします。

この記事では、名前空間について詳しく説明しています: http://www.blackwasp.co.uk/Namespaces.aspx

また、最後に命名規則の例がありますが、命名規則はあなたの呼び出しです! ;)

とはいえ、私が働いたほとんどの場所と私が一緒に働いた人々は、その会社のタイプ名を区別できるようにするため、賢明な会社名で始まります(他のライブラリ、ベンダー、オープンソースプロジェクトなどとは別です)。

于 2009-12-04T14:24:01.627 に答える
2

名前空間ごとにフォルダーをソリューションに追加できます。単一の実行可能ファイルにコンパイルされますが、ソースファイルが整理され、(私が思うに) 望ましい効果が得られますか?

通常、プロジェクトの名前空間ごとにフォルダーを追加し、同じ階層 (MyApp.View.Dialogs など) に従ってそれらを入れ子にします。

于 2008-09-11T02:30:49.607 に答える
2

名前空間は純粋にセマンティックです。通常はフォルダー構造を反映しますが、少なくとも Visual Studio IDE を使用する場合は、その必要はありません。

複数のライブラリで同じ名前空間を参照することができます。見苦しいですが、本当です。

于 2008-09-11T02:31:13.897 に答える
1

私は常に、ソース ファイルの編成と、クラスとオブジェクトへの識別子の割り当ては、2 つの別個の問題であると考えてきました。私は関連するクラスをグループにまとめる傾向がありますが、すべてのグループを名前空間にする必要はありません。名前の競合の問題を解決するために (多かれ少なかれ) 名前空間が存在します。C のようなフラットな名前空間言語では、や のmycompany_getcurrentdateような識別子につまずかずに 2 フィート歩くことはできません。MYCGetCurrentDateパーティー (またはシステム) ライブラリは、はるかに小さいです。論理的な分離ごとにパッケージまたは名前空間を作成すると、(Java の例では) のようなクラス名が得られますがjava.lang.primitivewrapper.numeric.Integer、これはかなりやり過ぎです。

于 2008-09-11T02:38:17.920 に答える