Doing some reading on Stack Overflow, I've found a lot of information suggesting that proper organization of a file system is crucial to a well-written web app. One of the key pieces of evidence is high-frequency references to "separation of concerns" in questions related to keeping programs organized.

Now, I've found some information on organizing file systems (Filesystem Hierarchy Standard) from 2004. It raises only two concerns: first, the standard's a bit dated, so I believe it may be possible to do better given the changes in technology over the past 8 years; second, and most important, my application is very small compared to an entire Linux distro. I think that the file system should be organized very differently because of that.

Here's what I'm looking at, currently:

    /www/dev/admin pages (php files)
      /www/dev/sites/content types (php/html files)
      /www/dev/sites/static pages (php/html files)
    /www/production/admin pages (php files)
      /www/production/sites/content types (php/html files; not a directory)
      /www/production/sites/static pages (php/html files; not a directory)
  • @FlorianMargaine Yes, the sites folder typically contains a shared directory.... I think that it's possible to get a more in-depth response than that answer drew, though. I'm hoping to see if there are any disadvantages to organizing things this way (for example, it seems a bit verbose, right now). Perhaps if I described the app more clearly, I could get better responses. Nov 22, 2012 at 11:02
  • 5
    Separation of Concern in software development does not necessarily have anything to do with the logical layout of the files on disk.
    – user
    Nov 22, 2012 at 12:34
  • 1
    Also, I must say that I find your "here's what I'm looking at" more confusing than anything. You may want to reformat it to make more sense to those of us who are not telepaths.
    – user
    Nov 22, 2012 at 15:23
  • 2
    I'm not saying that either separation of concern OR proper file system layout is bad. I am saying that they are two very different things.
    – user
    Nov 22, 2012 at 15:48

1 Answer 1


There is no single structure which can fit all the cases. For example, if I compare the tree you quoted in your question with a web application I'm currently working on, it doesn't fit. For example, they separate static pages, while the separation between static and dynamic pages makes no sense in my context of my current app. They create a separate directory for CSS, while I have a single stylesheet which I put at the root and am happy to find it there. I don't have includes, but helpers and something comparable to partial views, etc.

If you create an application which stores and displays events, the logical structure would be by year, then by month, and finally by day.

If you create an application which has three logical parts in it, it should be reflected in the tree.

Also remember that actual file tree is only a tiny part of the project structure; for example, in ASP.NET MVC, nothing forbids you from creating your own virtual path provider and host data in a database rather than as files if it is more convenient and easy to understand for you and other developers who will work on your project later.

Sticking to a file structure some team invented to fit precisely their project needs is not a good idea in this regard.

  • Thanks. This gave me some perspective. It says more to what I expected: this question asks for sharp, case-by-case answers. So, I need to be specific about the software when thinking about the file system. What I have now seems to work for my app, so I'm going to try it. Your case studies are also helpful. Nov 22, 2012 at 22:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.