I remember reading once (I believe the book was the .NET Framework Design Guidelines) that when you are designing a framework or class library that you should take care in how you arrange the classes in your namespaces. Specifically, classes in parent namespaces should have no knowledge of classes in child namespaces. Conversely, it is perfectly alright for classes in the child namespaces to know about the classes in namespaces above them.
For example, the classes in the System namespace don't know anything about the classes in the System.Data.SqlClient namespace. However, classes in System.Data.SqlClient know about the classes in System and in System.Data.
Now, taken at face value, this is a pretty straightforward idea. But there are occasions where this isn't as easy to implement as you might think. Classes are inherently coupled to one another by their very nature. For example:
- A business class
- The data entity class
- The class that maps a data entity class to a business object class
- The classes that serialize the data entity to and from the database
Granted, you can separate these into separate, discrete classes that clearly isolate the data and functionality; that isn't my problem. My problem is how to properly arrange them into namespaces that observe best practices for namespaces.
This has always seemed a bit murky to me. I've never seen it clearly addressed, and most samples I've seen have simply placed the data objects off the root namespace (MyProject.DataObjects) or something similar. It's as if noone is really sure, so we just don't talk about it.
I can see that, within the .NET Framework itself, classes reach across namespace boundaries all the time to access the functionality they need. Classes frequently access functionality from System.Collections, System.Collections.Generic, System.Runtime, System.Configuration, System.Reflection, and so on.
It's as if there's an unspoken rule that states that, when it comes to namespaces, "You can't know anything about your own children, but you can know all there is to know about the children of your grandparents, aunts, uncles, neices, nephews, and cousins." This guideline seems counter-intuitive and senseless to me; it seems to complicate namespace design.
So Here's the Question
How do you design namespaces in your own large applications? Are you really all that concerned about preserving namespace boundaries? If so, how do you resolve issues where classes are clearly related (despite having been decoupled as much as you can manage)?
I'm really interested in your experiences, and your input on this. It's been bugging me for a while now. If you could provide an example of namespace arrangement for a 3-tier application that included business objects, data entities, and so on, it'd be great. I'd really like to see how you guys arrived at your namespace models, and why.
Thanks very much in advance!