i've recently refactored a medium sized application and one of the jobs was to split commonly used code to different projects.
Now, lets say that commonly used namespace structure is
Core.Interfaces - for the main application
with an interface of IFoo
and for each specialized/external/referenced assembly i decided to make an extension to that, like
Core.Interfaces.Html
with an interface of IBar
the main application's Core assembly is located in a project named Core with a default namespace of Core while for the Html assembly i made a project named HtmlCore with a default namespace of Core.
The result effect (and the reason i selected this particular methodology) is that once you have referenced the Html assembly the using statements would not have to be updated and the net effect is
Core.Interfaces.IFoo fooIf;
Core.Interfaces.Html.IBar barIf;
or with a using statement of Core.Interfaces the above is transformed to
IFoo fooIf;
Html.IBar barIf;
This implicit namespace structure is a direct result of dependencies and it really has served us well as it makes project namespace maintenance a lot easier and the only thing someone has to have is the reference to the assembly. The structure is similar to what microsoft already does on the .net framework.
The thing is that i have second thoughts and (for future projects) i am considering a namespace structure that is explicit for each assembly like:
Core.DataInterfaces
Html.Core.DataInterfaces
So, has anyone worked with the explicit structure, both or even something else i haven't tried? I am open to suggestions and i am searching for the best solution as the target is to free up time from maintenance and confusion in the team during development.
Organize your namespaces however you see fit for your projects. Namespaces are for logical separation to avoid nameing collisions but are obviously great for organizing your code.
Remember, you can always give usings an alias.