フレームワークまたはクラス ライブラリを設計するときは、名前空間内のクラスをどのように配置するかに注意する必要があると読んだことがあります (この本は .NET Framework の設計ガイドラインだったと思います)。具体的には、親の名前空間のクラスは、子の名前空間のクラスを認識してはなりません。逆に、子の名前空間のクラスが、その上の名前空間のクラスを認識していてもまったく問題ありません。
たとえば、System名前空間のクラスは、 System.Data.SqlClient名前空間のクラスについて何も知りません。ただし、System.Data.SqlClientのクラスは、 SystemおよびSystem.Dataのクラスを認識しています。
さて、額面どおりに考えると、これは非常に単純なアイデアです。ただし、これを実装するのが思ったほど簡単ではない場合もあります。クラスは、その性質上、本質的に相互に結合されています。例えば：
- ビジネスクラス
- データ エンティティ クラス
- データ エンティティ クラスをビジネス オブジェクト クラスにマップするクラス
- データベースとの間でデータ エンティティをシリアル化するクラス
確かに、これらをデータと機能を明確に分離する別個の個別のクラスに分けることができます。それは私の問題ではありません。私の問題は、名前空間のベストプラクティスを遵守する名前空間にそれらを適切に配置する方法です。
これはいつも私には少し曖昧に思えました。これが明確に対処されているのを見たことがありません。私が見たほとんどのサンプルでは、単にデータ オブジェクトをルート名前空間 (MyProject.DataObjects) または類似のものから切り離していました。誰も本当に確信が持てないかのように、私たちはそれについて話しません.
.NET Framework 自体の内部では、クラスが常に名前空間の境界を越えて、必要な機能にアクセスしていることがわかります。クラスは、 System.Collections、System.Collections.Generic、System.Runtime、System.Configuration、System.Reflectionなどの機能に頻繁にアクセスします。
名前空間に関しては、「自分の子供については何も知ることはできませんが、祖父母、叔母、叔父、姪の子供について知っておくべきことはすべて知ることができます」という暗黙のルールがあるかのようです。 、甥、いとこ。」このガイドラインは直感に反し、無意味に思えます。名前空間の設計が複雑になるようです。
だからここに質問があります
独自の大規模アプリケーションで名前空間をどのように設計しますか? 名前空間の境界を維持することについて本当に心配していますか? もしそうなら、クラスが明らかに関連している問題をどのように解決しますか?
私はあなたの経験と、これに関するあなたの意見に本当に興味があります. しばらくの間、私を悩ませてきました。ビジネス オブジェクト、データ エンティティなどを含む 3 層アプリケーションの名前空間の配置の例を提供できれば、それは素晴らしいことです。どうやって名前空間モデルにたどり着いたのか、そしてその理由を知りたいです。
よろしくお願いします！