DeviceクラスがネームスペースProj.Devicesにあります。このクラスは、名前空間Proj.Devices.MessagesにあるMessageクラスにアクセスできますか？どちらのクラスも同じプロジェクトにあります。私はこれが可能かどうか尋ねていないが、これは悪い習慣かどうか？子ネームスペースにある親ネームスペースアクセスクラスのクラス
私はこのプロジェクトを別々のプロジェクトに分割すると循環参照に問題があると思いますが、それ以外の場合はこの確認が必要ですか？
編集： 私は、ネストされた名前空間が含む名前空間内の型に依存しなければならない」Namespace Naming Guidelines
でこれを発見した例えば、System.Web.UI.Designのクラスは、クラスに依存します。ただし、System.Web.UIのクラスはSystem.Web.UI.Designのクラスに依存しません。
はい、名前空間はクラスのグループ化です。 いいえ、悪い習慣ではありません。通常のシナリオです。
両方の名前空間からのクラスが互いに別のプロジェクトでそれらを持っていることはお互いに良い言い方をしているのであれば、同じプロジェクトであれば問題ありません。
私はそれを読んだのは悪い習慣であり、そのような状況を避けようとしました。結果として、私はより良い組織プロジェクトを持っていると思う。良い例はプロバイダパターンです。具体的なプロバイダは、子名前空間Pr.DevAccess.Providersにあり、インタフェースはPr.DevAccessにあります。具体的なプロバイダはDeviceAccess名前空間の型に依存することができますが、その逆もありません。私はこれらの2つのルールに従います。 1. \t共通の親を持つ同じ名前空間レベルにあるクラスは、相互に依存する可能性があります。 2. \t子名前空間にあるクラスは、親名前空間の型に依存することはできません。 – userx01233433
実際には、私はいつもルートの私のメインクラスの設定、キャッシュ、マネージャー、ヘルパーなどの機能をサポートするための多くのサブフォルダで終わります。そのサブフォルダは子名前空間を持ち、親名前空間のクラスによって使用されます。あなたが言ったことは、WCLにとってうまくいくかもしれません。 – Morbia
申し訳ありませんが、私はBCL（基本クラスライブラリ）WCLではないことを意味します。 – Morbia
私はMorbiaに同意できません。名前空間は単にグループ化するためのものではなく、アセンブリが具体的な分離（レイヤーと懸念事項）である論理的な分離（コンポーネント）です。
これらは、しばしば階層的に見えます。哲学的には、この特定の子要素なしで存在することができる、親を介して階層内のより低いものが存在する。
これは、最近、Core名前空間が存在する理由だと思います。ベースネームスペースは基本構造/基礎のみです。
サブネームスペースがベースネームスペースで使用されている場合、ほとんどの場合相互依存関係が存在することが確認できます。これはアーキテクチャの危険性を示します。
それは避けなければならない理由は次のとおりです。
あまり理解できるだろう。しかし、あなた自身がこの質問をしているのであれば、あなたは既に良いコードを書くことを考えています。
アーキテクチャは、時間と美しさだけではない程度です。そのような慣行が高い結合を回避するために存在する理由
です。特定の成熟度では、アーキテクチャーレスコードは であり、保守性が低く、理解しにくくスケーラビリティが劣ります。
状況によっては循環参照が発生する可能性がありますが、他の名前空間クラスを継承または参照することはまったく間違っていません。そのような良い例の1つは、カスタムコントロールを作成する必要がある場合です。他のネームスペースの呼び出しsystem.windows.controlsなどを参照してください。 –