There are quite a few things to consider in organizing your structure, or else maintanance or understanding the code becomes a nightmare (even if you revisit after a few years).
A similar question was asked in an earlier best practices post.
Some rules I follow are:
- Keep all projects in one folder
("Projects"), keep solutions in
another folder ("Solutions"). That
way you can have any solution use
any projects, esp useful if you have
common framework-type projects, Keep all the dependent assemblies separate.
- Namespace should indicate the
intrinsic functionality of the code,
not company, not type not
departments, nor something too generic or superfluous (Company.Data eg) . I have worked on
projects where company names have
changed and had to go thru some
tedious refactors, but using company
name seems to be the norm in .Net
world. Sometimes makes sense,
sometimes not. Refactoring is not
simple in SP, as code references are
in wsp, cdb, config files, webpart
pages etc. Naming by project has less chances of changing names and external dependencies.
- In anycase, the intrinsic
functionality of the module never
changes (order is always an order),
so it is useful to have namespaces
reflect that and put all order related stuff in it. Adding types to
namespaces seems superfluous to me
in most cases, but occasionally it is useful.
- If your marketing webcontrol is
generic enough and will be used by
somebody else tomorrow, or your
marketing is renamed or merged to
"sales", you have a code that
- With VisualWebParts, now webpart
code and webcontrols are generated together by VS2010. So unless its a webcontrol all of its own without a webpart, may be you can have it a WebControls namespace.
In general, I have seen Functional namespacing makes it quicker to understand the overall relationship of different modules without having to worry about how it is implemented.