Best Practices for Code Organization
-
Hi folks, i'm relatively new to this area of things although i have been using C# for many years. I have been trying to find a starting point for organizing my code for medium sized projects. What i am after is a relatively detailed example of how a software application solution would be organized in Visual Studio. For example if i worked for company CMP and had an application i wished to create named AppX, no doubt i would start with a solution named: CMP.AppX .. and then begin adding projects. I am aware that every situation would be different and would require different projects and namespaces, but i would like an example of how you guys would go about doing it and some reasons for your choices. eg: CMP.AppX CMP.AppX.Data CMP.AppX.UI CMP.AppX.UI.Desktop CMP.AppX.UI.Web CMP.AppX.Webservices CMP.AppX.UnitTests CMP.AppX.Reporting ...and how this would be achieved - what was a project and what was subdir in the project folder etc. Thanks in advance.
-
Hi folks, i'm relatively new to this area of things although i have been using C# for many years. I have been trying to find a starting point for organizing my code for medium sized projects. What i am after is a relatively detailed example of how a software application solution would be organized in Visual Studio. For example if i worked for company CMP and had an application i wished to create named AppX, no doubt i would start with a solution named: CMP.AppX .. and then begin adding projects. I am aware that every situation would be different and would require different projects and namespaces, but i would like an example of how you guys would go about doing it and some reasons for your choices. eg: CMP.AppX CMP.AppX.Data CMP.AppX.UI CMP.AppX.UI.Desktop CMP.AppX.UI.Web CMP.AppX.Webservices CMP.AppX.UnitTests CMP.AppX.Reporting ...and how this would be achieved - what was a project and what was subdir in the project folder etc. Thanks in advance.
We organize our projects normally in this way: 1) One solution for all projects we are currently developing. Developing with several solutions at once is very cumbersome. 2) However, if there are components that can be extracted in some sort of library or framework then do it (only feasable for components that can be developed independently for the most part, because of 1) 3) If our system is built up from different "sub-systems" (sometimes there is a relationship with tiers, but it's possible to have either several sub-systems per tier or viceversa) then we arrange them within solution folders (note that solution folders are virtual folders and that there are no folders in file system for them). 4) We try to keep the number of projects limited because a large number of projects has a negative effect on build performance. Therefore we wouldn't arrange our project the way you suggest in your post (propably). Keep in mind that assemblies are a deployment unit, nothing else. There is no problem in packing several components into a single assembly, as long as they are deployed together. Requirements on releasing individual components can however be a reason to seperate components into different assemblies. 5) For each project we habe an additional unit test project to seperate the tests from production code. We use a naming rule: for project MySystem.MySubsystem.MyWhatever.dll exists a MySystem.MySubsystem.MyWhatever.Test.dll. This simplifies out NAnt script for building, testing and releasing our software. 6) Namespaces are hierarchical and should be used in this way. That means that we express abstractions with namespaces. E.g: MySystem.MyComponent contains everything that is used in that component and MySystem.MyComponent.MyImplForCaseX contains the details for a specific extension while the code in the subnamespace can access the content of its parent namespace. This results in very little access to sibling or child namespaces, thus supporting loose coupling of components. 7) We use subversion as version control system. With the following structure (this is however really project specific): root/ trunk/ doc/ source/ libs/ contains all 3rd party dlls our projects reference, built up with svn-externals and real dlls scripts/ contains all NAnt scripts for building, unit testing and releasing tools/ tools used for building etc. releases/ Release 1.0/ [trunk/] only if release is modified (bug fixes)
-
Hi folks, i'm relatively new to this area of things although i have been using C# for many years. I have been trying to find a starting point for organizing my code for medium sized projects. What i am after is a relatively detailed example of how a software application solution would be organized in Visual Studio. For example if i worked for company CMP and had an application i wished to create named AppX, no doubt i would start with a solution named: CMP.AppX .. and then begin adding projects. I am aware that every situation would be different and would require different projects and namespaces, but i would like an example of how you guys would go about doing it and some reasons for your choices. eg: CMP.AppX CMP.AppX.Data CMP.AppX.UI CMP.AppX.UI.Desktop CMP.AppX.UI.Web CMP.AppX.Webservices CMP.AppX.UnitTests CMP.AppX.Reporting ...and how this would be achieved - what was a project and what was subdir in the project folder etc. Thanks in advance.
I tend to follow these when possible; http://msdn.microsoft.com/en-us/library/893ke618(VS.71).aspx