Project structure

Pretty much all projects I start have a similar folder structure. I've not found anything that this structure doesn't work well for (in MVC projects these sit right along beside the standard ones). I'll list them first, then go into detail.
  • /Config
  • /Core
  • /Customization
  • /Extensions
  • /Models
  • /Repositories
  • /Services
  • /App.cs


This is directory I place any type of config classes. In most cases you'll Ninject and Automapper registrations here. In MVC apps the routing, filters, ect.. are also located here. You'll find very little logic in these classes, if any at all.


This directory is for classes that are fundamental to the application. In most cases you'll find data access classes (like Linq2Sql or EF) and Caching Classes. If I have any custom generic data types (ex. Money) I usually place them in a subdirectory named "Types".


This is where a put any class I create which extend an existing class in .net or 3rd party library. The best example is probably a custom Membership or Role provider.


Any and all extension classes and methods.


After learning MVC I've adopted the models folder for all data models in every project I work on. The only thing in here should models for holding and transporting data. I usually annotate my models for WCF or MVC. The only logic I may add, would be ToString or Equals overrides.


Back when I was starting out with MVC, I ran through a number of tutorials on the Repository Pattern. I came to adopt that terminology. To me repository class are data access of any kind go. The data source could be a database, file, web service, etc... doesn't matter any external data is brought in through a repository class abstracting away the original data source.


Any real logic I usually do in a service class. Examples would be, Template Parsing, Serialization, Price calculations, Complex filtering, etc.. This gets a little confusing with wcf services, I'm still trying to come up with a good convention to distinguish the two.


I usually have a static App class. This where my application startup logic and any global methods live. About the only thing I ever have in here is an abstraction of AutoMappers' Mapper.Map method. Everyone once in a while when I've no other option, I may add abstracted access to the dependency injection container.

Last edited Sep 12, 2013 at 2:30 PM by amsprich, version 2