名前空間とクラス名のガイドライン

15

utilsやその他のヘルプクラスが関係しているときに、クラスとサービスの名前を正しく指定できません。

以下をどのように構成しますか？

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

等...

上記のサービスと同じニーズを持つ複数のサービスがあります。1つの考えは、このすべてを適切なネームスペースに分けて、次のように見えるようにすることです。

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

等々。もちろん、すべての名前空間は個別のフォルダーです。しかしDateValidators、他のサービスにはおそらくもっと多くのものがあるため、これは100％ではありません。

またServices.EventService.EventService.cs、名前空間にクラス名が含まれていますが、これも良くありません。を使用できますServices.Event.EventService.csが、もちろんその名前のエンティティは既に存在します。

これがドメインモデルです。

c# architecture

— マティアス
ソース

「上記のサービスと同じニーズを持つ複数のサービスがあります。」これは、複数のサービスが上記のコードを使用しているのか、複数のサービスが同じパターンに従って独自のバージョンを提供する必要があるという意味ですか？

— ナタナエル

同じパターンの独自のバージョンを提供すること

— マティアス

5

私はあなたがここにあなたの名前空間を改善するために行うことができ、単一の最大のものは削除することだと思うServiceあなたのEventService名前空間。また、名前空間を次のように調整します。

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

しかし、それでも改善が必要だと思います。

以前は名前空間が好きでしたが、最近は少ないほど多いと思います。名前空間を深くネストすると、コードが冗長になりすぎる可能性があり、物事をはるかに細分化すると、継承能力が低下します。たとえば、コードでは、DateValidatorクラスは他の場所で簡単に使用できます。そのため、EventService以外のサービスはDateValidatorクラスを利用できるため、その上に多くの名前空間はありません。同じことが拡張メソッドにも当てはまります。すべての拡張メソッドを同時に表示する必要がある時間はありません（私が見ることができます）。したがって、関連するものでグループ化する方が理にかなっています。この場合、EventExtensionsおそらくにリンクしているEventServiceので、論理的には私の意見では一緒に座っているはずです。

— カール・ニコル
ソース

プロジェクトが大きすぎて、特定のレベルに分割できない。イベント名前空間のDateValidatorはイベント固有のケースのみを処理するため、他の場所では使用できません。私はサービスが好きです。イベント .EventService。どうして私はそれを考えることができませんでした。リファクタリングの時期だと思います！

— マティアス

@Mattias-それは公平です。私の知る限り、名前空間は（Saeedが以下で言及するような基本的なガイドラインを超えて）好みの問題に過ぎません。

— カールニコル

5

普遍的なパターンに従って、Microsoftの一般的な命名ガイドラインと名前空間の命名ガイドラインを読んでみませんか？

数式<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]はうまく機能すると思います。

— サイード・ネアマティ
ソース

2

適切な名前空間の設計では、論理設計と物理設計の両方が考慮されます。

名前空間の元々の理論的根拠は、主にオブジェクト名とメソッド名の間の名前の衝突を防ぐことでしたが、全体的なソリューションアーキテクチャと設計において重要な要素になりました。概念階層と論理設計を意味のあるものにするだけでなく、コードを適切に設計された再利用可能なライブラリにきちんとパッケージ化し、後で他のプロジェクトや製品に簡単にバンドルできるようにする必要があります。それはおそらく、優れた物理設計の望ましい結果です。

.NET Frameworkと、適切なサイズのアセンブリで関連機能のユニットがどのように提供されるかを見てください。参照とusingステートメントをドロップすると、キッチンシンクをいくつもドラッグすることなく、関連する機能が突然使用可能になります。これは、インテリジェントなネームスペースを含む.NET Frameworkの物理設計が、物理的に関連する展開可能なユニットに論理的に関連するコードをパッケージ化したためです。名前空間とアセンブリの間の優れたマッピングを作成することにより、Microsoftの.NETフレームワークのアーキテクトと開発者は、作業を大幅に簡単にしました（もちろん、そうでないと主張する人もいるかもしれませんが、彼らが何をしたかはかなり嬉しいです）。

C＃の名前空間は、実際にはかなりarbitrary意的です。名前空間を最も奇妙な場所、互いに遠く離れたアセンブリに配置できます。この分野で役立つ規律は、よく整理されたソフトウェア製品への個人的な貢献です。私は、それぞれの場合に何をすべきかを正確にアドバイスすることを敢えてしません。この答えで達成したいのは、名前空間を定義するときに、論理設計だけでなく物理設計についても考えてもらうことです。物事を論理的に関連付け、デプロイ可能に（物理的に）バンドルすればするほど、あなたと、いつかコードを処理する必要があるかもしれない他の人の両方にとって、物事は後で簡単になります。

したがって、名前空間の問題を解決するときに、コードがアセンブリおよびコンポーネントにどのようにパッケージされるかについて考えてください。

— ジョン・トブラー
ソース