Over time, the code base I maintain has grown exponentially. We have a variety of different utility classes, webparts, event receivers, console applications, and more.
Typically, each webpart lives in a separate DLL (one solution and one project per web part). Our utility classes have also been largely separated out into their own separate DLLs (this includes any specialized list access classes that get grouped with their beans together in a DLL). This has led to a large amount of solutions which has become more difficult to maintain (upgrading each solution to Visual Studio 2008, or simply just trying to find out the maze of DLL references).
With my discovery of the SharePoint Guidance, I’m re-evaluating our current code structure. For example, it looks like they recommend combining all of your specialized list access classes into a Repository (we’ve done completely the opposite so far by splitting them into DLLs based on what “solution” the code is for).
Questions: How should I be organizing my code? How do you decide what goes into a solution vs project vs folder or what goes in a namespace? One solution per web part?
I usually organize my code by functionality. Let’s say I’ve got an extranet project and some code for some intranet webparts, I seperate it out into a Extranet and an Intranet project, and seperate the different classes of code (eventreceivers, timerjobs, webparts, etc.) into different namespace.
That way, I can deploy (sub)sets of functionality to different farms if I want to, and when editing code I got everything that depends on one another in the same place 🙂