Dear friends,

In many of the sample ASP.Net projects, I am seeing a folder structure with

1) all model classes in Components folder

2) all user controls in UserControls folder

3) All javascripts in JS folder

etc. etc. I think this is the standard folder structure suggested by Microsoft.

But, I prefer a folder structure that is dependant on project modules. Since I am using UML to model projects, I have a list of entities and methods connected to entities. I prefer to have one folder for each entity and put all JS files, User controls, Model class, custom controls (specific to that entity) in the single folder. I find this to be more scalable and developer friendly as there are only few files in a folder. Also, I can assign folder level access to developers.

For e.g. let Students, courses and subjects be 3 entities in a University mgmt. software. In my project, there will be 3 folders namely Student, Course and subject. All class files, aspx files, JS files and controller files associated with Student entity is put in Student folder alone.

In the first folder structure I mentioned, class files, aspx files, user controls etc. associated with one entity is scattered in many folders. That method is also not scalable. When the project expands to include 500 entities, There will be atleast 500 class files in Components folder (which is cumbersome to work with).

I have not seen any project following my folder structure. So, I become dubious about its advantages / disadvantages. May I know whether there are any disadvantages for my folder structure ? Why most of the people are following the first folder structure I mentioned ?

If you get to the point that you have 500 entities in a project, then it's time to think about breaking the project up into other projects. Subdivide the project into logic groupings of code (business logic; database logic; UI elements). This is a better approach to just dividing up the code peices into folders within the same project.

Your approach may seem logical when you have single bits and pieces that work in small logic units (A student, A course, A subject). But in reality, all the elements will have to play together in code. A Course may have a collection of students in it. A Student may have a collection of Courses they are taking. So is there really anything gained by breaking up your project structure by these types of entities?

In our setup we have 13 class libraries in the primary application solution. 1 is a web application which serves as the front end to the entire application. The other 12 class libraries are divided up into such things as: Constants/enumerators; business entities; data access; business logic (several for different areas of the application); helpers (tools and such); custom controls. The web application project is divided into directories to separate logic areas of the application. It becomes quite difficult to manage a large web application if every file lives at the root. But a significant portion of the support codebase is found in completely other project assemblies where the various classes live together.

Sometimes accessive organization can be a bad thing.

-Peter