Visual Studioのデフォルトの名前空間の命名規則との戦いをやめるべきですか？
私はMVVMプロジェクトに取り組んでいるので、Models、ViewModels、Windowsなどのフォルダーがプロジェクトにあります。新しいクラスを作成するたびに、Visual Studioはプロジェクトを保持するだけでなく、名前空間の指定にフォルダー名を自動的に追加します。レベル名前空間。したがって、ViewModelsフォルダーに新しいクラスを追加すると、名前空間MyProject.ViewModelsだけではなくMyProject。
私がこれに最初に出会ったとき、それは私を苛立たせました。私のクラス名はかなり明確で、中にはフォルダーの名前が含まれていることもあります（例：ContactViewModel）。名前空間のフォルダ名を手動で削除してしまいました。ある時点でカスタムクラステンプレートを作成しようとしましたが（ この質問 を参照）、それを機能させることができなかったため、手動で続けました。
けれども、この慣例が私には見られないという正当な理由で存在するのかどうか疑問に思い始めました。何らかの理由でフォルダに整理された同一のクラス名のセットが多数ある場合に便利ですが、それは特に一般的なシナリオのようには見えません。
質問：
- ネームスペース名がフォルダー構造を反映するのが一般的な慣習なのはなぜですか？
- この規則を順守していますか？どうして？
あなたと同じ-私はこれを最も長い間戦った。次に、なぜフォルダを作成するのかを考え始めました。任意のバケットの代わりに名前空間とパッケージを表すフォルダーを作成し始めた。
たとえば、MVVMプロジェクトでは、ビューとビューモデルを別の名前空間に配置すると役立つ場合があります。 MVCには、モデル、コントローラー、ビュー用の個別の名前空間があります。クラスを機能ごとにグループ化することも有益です。
突然、プロジェクトはより組織化されたと感じます。他の開発者にとって、機能が実装されている場所を見つけやすくなります。
名前空間のプラクティスを標準化すると、すべてのプロジェクトが同じ予測可能な構造を持ち、メンテナンスにとって大きなメリットになります。
確かなアドバイスが必要な場合は、購入をお勧めします フレームワーク設計ガイドライン：再利用可能な.NETライブラリの規則、慣用句、およびパターン これにより、実際のフレームワーク設計チームから知っておく必要があるすべてが得られます。
...名前空間に名前を付けるときの目標は、フレームワークを使用するプログラマが名前空間の内容が何である可能性が高いかを即座に知るための十分な明快さを作成することです...
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
そして重要なのは
名前空間とその名前空間の型に同じ名前を使用しないでください
Visual Studioの方法に従った場合、修飾または使用する必要がある名前空間の沼地があるため、1/2タイプごとに名前空間に断片化しても、最初の要件を満たしません。例えば
コア-ドメイン-ユーザー-権限-アカウント
作成しますか
- MyCompany.Core.Domain.Users
- MyCompany.Core.Domain.Permissions
- MyCompany.Core.Domain.Accounts
あるいは単に
- MyCompany.Core.Domain
Visual Studioの方法では、前者になります。また、小文字のファイル/フォルダーの名前を使用する場合は、毎回クラスの名前を変更し、1つの大きな名前空間のもつれを作ります。
その大部分は常識であり、youが独自のAPIまたはフレームワークのコンシューマーである場合に、名前空間がどのように編成されるかを実際に期待することになります。
私もこれに悩まされましたが、大規模なコードベースでプロジェクトを操作してリファクタリングすると、すぐにそれ以外のことを学びました。この概念を採用したことで、コードを「物理的に」論理的に構造化するのに非常に良い方法だと思います。大規模なプロジェクトがあり、名前空間がフォルダと一致しない場合、ファイルをすばやく見つけることが難しくなります。物事がどこにあるのか覚えるのもはるかに難しい...
また、ReSharperが推奨する場合は、おそらくそれは良い考えです。例えば。クラスの名前空間がそのフォルダー名と一致しない場合、R＃は文句を言います。
ファイルシステムフォルダーと名前空間はどちらも階層を表します。この2つを一致させることは、私にとって完全に自然なことです。さらに一歩進んで、ファイルとクラスの1対1の関係を使用します。 C++などの他の言語でプログラミングする場合もそうします。
これら2つの階層間の関係について質問したところで、ファイルシステム階層で何を表現したいのかを真剣に考えます。
規則に従わない1つの方法は、プロジェクトのルートフォルダーにファイルを作成し、それを最後のサブフォルダーに移動することです。
とにかく、それは私が実際に好きな慣習です。タイプをフォルダーに分割している場合、おそらくそれらのタイプには、フォルダーに関連するある種の概念的なグループがあります。したがって、意味をなさず終了し、それらの名前空間も同様です。 Javaはこのアプローチを採用し、パッケージシステムでそれを実施します。最大の違いは、言語もCLRもそれを実施しないため、VSはそれを「提案」するだけです。
論理構造と一致する物理構造が役立つことは他のすべての人に同意しますが、Visual Studioの自動命名と戦うことも言わなければなりません。クラスの名前を変更しなければならない理由は6つあります。
- ルートの「src」フォルダーを使用して、コードを埋め込みリソースから視覚的に分離します
- 別の大文字を使用したい
- 名前空間内で整理するために、コードをサブフォルダーに整理します
- インターフェイスを実装や基本クラスから分離したい
- そんな感じ
チオセの理由で、私は自分が作成するすべてのクラスでそれらを調整する必要があることに自分を辞任しました。この問題を回避するための私の戦略は、必要な名前空間宣言を持つファイルをコピーして、すぐに内容を削除することです。
C++で名前空間が導入される前は、すべてのCタイプはグローバル名前空間にありました。名前空間は、タイプを論理コンテナーに分離するために作成されたため、どのタイプが参照されているのかは明らかでした。これはC＃にも適用されます。
アセンブリは展開の決定です。 .Netフレームワークを見ると、特定のアセンブリには複数の異なる名前空間が含まれています。
フォルダはディスク上のファイルを整理するためのものです。
3つは互いに何の関係もありませんが、多くの場合、アセンブリ名、名前空間、およびフォルダ名が同じであると便利です。 Javaは、フォルダーと名前空間を同じものに折りたたみます（ファイルと名前空間を編成する開発者の自由を制限します）。
プロジェクト内のファイルを複数のフォルダーに整理することを選択することがよくあります。これは、私または私のチームがファイルをナビゲートしやすくなるためです。通常、このファイル編成は、使用する名前空間の設計とは関係ありません。 VSチームが名前空間をフォルダー名と同じにデフォルト設定しないか、少なくともこれをデフォルトにしないようにオプションを戻したいと思います。
新しいファイルの作成後に、新しいクラスのテンプレートを変更するか、名前空間を修正してください。
名前空間とプロジェクトフォルダの構造が異なるのは確かに正当な理由があると思います。ライブラリを開発している場合、名前空間構造は何よりもまずAPIのsersに対応する必要があります。論理的で把握しやすいはずです。一方、フォルダ構造は、基本的にAPIデザイナのように、使いやすくするために存在する必要があります。構造も論理的である必要があるなど、いくつかの目標は確かに非常によく似ています。しかし、異なるものもあります。ツール用の関連ファイルをすばやく選択できること、またはナビゲートが容易であること。たとえば、私は特定のファイルのしきい値に達したときに新しいフォルダーを作成する傾向があります。そうでない場合、探しているファイルを見つけるのに時間がかかりすぎます。しかし、デザイナーの好みを尊重することは、名前空間を厳密に守ることも意味します。
したがって、全体として、多くの場合、両方が一致することは理にかなっていますが、逸脱する正当なケースがあると思います。
過去に私にとって役に立っていたのは、ファイル（WPF UserControlなど）を1か所に作成して名前空間を正しく設定し、それを「正しい」フォルダーに移動することでした。
また、Visual Studioのこの「デフォルト」の動作には苦痛を感じます。
また、Visual Studioは、LinqToSql .dbmlファイルを独自のディレクトリに配置すると、名前空間/ディレクトリの一致を設定しようとします。 .dbmlを編集するときはいつでも、次のことを覚えておく必要があります。
.dbml.designer.csファイルを開くnamespace宣言からディレクトリ/フォルダー名を削除する
ただし、 この動作を停止する する方法はあります。カスタムクラステンプレートの作成が含まれます。
名前空間の階層とフォルダーの階層を一致させることは便利であり、良い考えだと私は同意しますが、Visual Studioがこの機能をオフに切り替えることをサポートしていないように見えるのは嫌なことだと思います。 Visual Studioには多くのアプリケーションがあり、ソースファイルフォルダーを完全に細かく構成するためのコーディングスタイルと方法がたくさんあります。
名前空間に属する何千ものファイルがあるとしましょう。しかし、プログラマーはファイルをフォルダーにグループ化して階層をナビゲートしやすくしたいと考えています。これは本当に悪い考えですか？これは本当に物事を保守不可能にするので、IDEによって禁止されるべきでしょうか？
Unityでの作業にVisual Studioを使用しているとしましょう。これで、すべてのスクリプトは "Assets.Scripts"名前空間にあります。現在スクリプトを含んでいない無用のAssetsネームスペースがあるだけでなく、「Assets.Scripts」は無意味です-ソースファイルがどのプロジェクトまたはプロジェクトの一部に属しているかを記述していません。役に立たない。