Are there some principles of organizing classes into namespaces?
For example is it OK if classes from namespace N depends on classes from N.X? And if classes from N.X depends on classes from N?
Are there some principles of organizing classes into namespaces?
For example is it OK if classes from namespace N depends on classes from N.X? And if classes from N.X depends on classes from N?
Classes ib N.X can rely on classes in N. But classses in N shouldn't rely on classes in N.X, that's bad design.
Some namespace guidelines: http://msdn.microsoft.com/en-us/library/893ke618.aspx
In general, that should be fine for your example, if your packages were "N.UI" and "N.Util". I've seen namespaces used in two general fashions:
1) All tiers of a system have a namespace (i.e. database, web, biz, etc.)
2) Each component has a namespace (i.e. Customer, Invoice) and tiered namespaced underneath
Either way, the sub namespaces would be inter-related packages within a larger namespace, so it would be perfectly fine for you UI code to depend on your domain objects.
However, while it would be fine for N.X classes to depend on classes from N, I don't think it would make much sense for classes from N to depend on classes from N.X - it sounds like you could use some reorganization in that case.