Structuring your application might not seem so important when you first start,  but over time your application might evolve from something tiny and neat to something gigantic and ugly and it might not be as easy as one might think to structure it in a consistent way. When it comes to structuring your application there are thousands of different ways of doing so and this is just my few cents on the topic after dealing with “morphing” applications myself and actually deciding to learn more about the subject. I will go into the subject from my perspective of .NET applications with web development in mind as it is what I work with most of the time.

Every application is built up in a different way and if one would want to the project don’t have to have any structure at all. Just put all files in one folder and call it a day. In reality though this is not a very efficient way of organizing it when it comes to collaborating and making it easy to navigate through your hundred or thousand file application. By organizing your files and code into an easy-to-understand manner everyone that works with it just might have a better day.

Don’t overdo small projects

This is a series of articles about application structure and we’ll get to the bigger ones in the next one. I just want to say this first. Don’t overdo small projects. I’ve had the pleasure of taking over projects where every possible design pattern and framework is used, even though the projects is rather small or that it grew into something where some patterns is not at all necessary. Simple applications also needs to be simple to manage, because that is probably what the customer and programmer expect. Lets get to the structuring.

Small application structure – ASP.NET MVC example

Note: Even though the example is ASP.NET MVC the principle might still work for whatever project you’re about to manage. No matter language och environment, these are after all just basic thoughts about organizing your applications.

Note 2: Decoupling and multiple projects will come in the next article.

When you create a new MVC project in Visual Studio you will get the following structure:

  • App_Data – Used for local data storage files i.e. embedded SQL, XML or whatever.
  • App_Start – Startup, routing and other configuration code-files
  • Content – Style Sheets (CSS), images
  • Controllers – MVC Controllers
  • fonts – Fonts
  • Models – aka DTO
  • Scripts – JavaScript
  • Views – MVC Views
  • Other files in the root directory. web.config, global.asax etc

This is indeed good enough for me for a project. With this out of the box structure the first thing I would like to add is a folder simply called Source. This is basically a folder for all my C#-files outside of the controllers and within Source is where I keep the actual code folder structure. The reason I choose to have this is to keep the existing project as clean as possible. People who work with ASP.NET MVC already knows the default folder structure, and I’m not about to mess with their heads more than necessary. Inside this magnificent folder of goodness lies what back end developers probably will spend most of their time, depending on application of course.

And here comes the reason I so much wanted to write this article to begin with. When building projects I have at numerous times googled for the “ultimate” project structure. I wanted someone to tell me “This is a great example of how a good application looks like and if you do this you will never encounter any trouble in the future to come”. Sadly though, I couldn’t find such an article, so I had to go into the deepest of Stack Overflow and other parts of the web to extract all the information that I could about folder structures and simply try my way forth. I still don’t think the journey is over when it comes to this subject though and it is important to always strife to become better. As with everything there will always be a newer and better way.

Inside the magnificent folder of goodness – Source

Welcome to the source folder. The structure looks like this:

  • Source
    • Types
      • Models – Other usable names could be DTO (Data Transfer Objects) or POCO (Plain Old CLR Object)
      • Interfaces
      • Abstracts
      • Enums
    • Helpers – Helper classes. By default static, but not recommended in IoC.
    • Handlers
      • EventHandlers
      • HttpHandlers
    • Extensions
      • StringExtensions
    • Exceptions
    • Attributes
    • Services – Application Services, which is where most logic will be written. Put in folders if more than one file is related.
      • UserService.cs
      • FileService – folder
        • FileService.cs
        • FileStreamService.cs
    • WebReferences – Web service references
      • Webservice 1

Note: I rather keep my Models inside the source folder. This battles the “default folder structure” I mentioned above when it comes to MVC, but not other projects such as ASP.NET Web forms.

This is what I wanted a long time ago, a reference for my application folder structure. I might have missed things that others might think is vital and if you do, please do share and we all might just learn something new from it. I am most willing to update my current reference structure design if needed. 

Part 2 in this series will go through larger applications.