Keeping your project files organized will help you navigate through your projects and help you find what you are looking for to make changes faster.

Here are some tips that I use to help keep my ASP.NET MVC solutions organized:

  1. Use multiple projects to separate sections of the program.
  2. Use folders to group interfaces, classes, and factories that deal with an object.
  3. If objects can be used by other programs, put them in their own class library project.

Option 1
When beginning a new program, I usually start by creating an ASP.NET MVC solution with 4 projects:

  • The main project – which contains the MVC components of the application such as Controllers, Views, CSS, and JavaScript files.
  • The unit testing project – which contains all of the requirements for the application along with any fake repositories used for testing.
  • The data project – which contains the repositories and domain objects used by the application.
  • The services project – which contains the service objects that are the middle-man between the Controller and the Repository.

Option 2
Folders are used within the projects to further organize the code files within. The data project could have a domain object called Operation.  Domain objects are placed in a folder with the same name as the object.  Interfaces, Repositories, and Factories that deal with the object are also placed in the domain object folder.

The service project is organized similar to the data project.

The unit test project is slightly modified from the default to create a folder which contains all fake repository objects and another folder to contain requirement tests. Depending on the detail of unit testing you wish to utilize, you may have unit tests that verify application requirements and/or unit tests that further verify other parts your code.

In my opinion, you can write application requirements that detail exactly what the program should do and as long as you unit test these requirements, you don’t need to waste time trying to unit test 100% of your program. If a bug is found later, it will most likely be because it was not an application requirement. Then, add a new requirement, write a unit test, and make the application pass the new test.

Option 3
Where I work, we have various databases that we need to communicate with. We wanted a way to use these databases the same way every time without having to remember all of the different objects and names that needed to be used by each. So, I developed a parent wrapper class around the basic database functionality and then individual wrappers around each database object that inherited from the parent wrapper. Now, we can call up any of the database connections and work with them in exactly the same way, the only difference between them is the call to the factory when creating the instance.

These database wrappers were added to their own separate project so that in future applications, we could continue to reuse them.