Optimum filesystem structure for scripting language MVC applications

Question

When I speak of scripting languages I am speaking of languages like Python, Perl, and (in my case) PHP. After using CodeIgniter, Zend, and lots of other fun MVC systems it seems clear that one thing one one seems to agree on is the folder structure (alongWithOTher things_like_that). This is really causing a problem for me because I can't find any good documentation on the benefits of different structure designs. Most people just recommend one because that is what they use without regard for improvements in design.

One of the things I hope we can all agree on is that checking the file system for existing files when autoloading classes is very bad practice. Our classes should not be in one of 5 possible locations causing a barrage of file_exists() checks for each library we load.

So anyway, I am trying to collect directory structures that I can compare to find the best practices when planning for applications that:

1. Are OOP based which most likely means MVC
2. Are International in scope and support language files/translations
3. Are open to modules/plugins so that complete packages can be dropped into our codebase
4. Clearly define what is going on and where to look for given classes
5. Possible support for multiple sites running off the same structure (see /site directories below)

So here is what I have so far. Keep in mind that libs is just a term meaning your main library/class directory and may even contain models depending on the folder structure. Also, I excluded any type of static content (JS/CSS/images) as that stuff is really an after thought and not related to our serverside code - it may even be on another server! The same thing with caches, file uploads, lang, and all other generated content.

/controllers
/views
/models
/libs
/config
index.php

This kind of reminds me of the Zend framework which piles everything into a single libs folder (which also includes subfolders to keep things organized). Only works for a single site.

---

/libs
/site
    /controllers
    /views
    /models
    /config
index.php

This would a multi-site version of the above structure.

---

/libs
/functions
/site
    /controllers
    /models
    /views
    /config
/site2
    /controllers
    /models
    /views
    /config
/modules
    /user
     /controllers
     /models
     /views
index.php

This would be version that would allow multiple sites and drop in modules. The modules would be self contained MVC apps like a forum which would include business logic, CRUD, and views.

So does anyone have a perfect structure they could share or guide me in choosing a good extend-able design?

Answer 1

Not to specifically recommend symfony, but rather it's approach, which I think is pretty good (but not "perfect")

Allows for:

• I18N
• Multiple environments (dev, qa, prod, etc)
• External libraries
• Plugins
• Multiple sites (domains or otherwise)
• Batch processing (command-line tasks)
• Unit tests
• Documentation
• Logging
• Caching

Also, among symfony's ups and downs, one thing I think it does pretty well is caching. And I don't mean template/view caching - I mean compilation-like caching.

When a project is executed the first time, symfony builds a master file of library classes which, upon successive hits to the application, not only removes dozens or even hundreds of stat calls per request, but performs other optimizations like the removal of comments.

It also caches configuration data and autoload information, all of which can be tweaked to suit your needs.

Answer 2

We use a structure similar to your last "multi-site" option for a mutli-site forum engine we built in house and it works out really well. You can always copy modules over if you need, and it also allows for the possibility of Site A customizing their module a little without affecting Site B.

When you get into practical applications of this, you're talking about completely separate teams, maybe even businesses using those two sites, a little division is not the worst thing. We also have a shared modules folder, but if you name a file the same thing in the Site's modules folder, it uses that version instead. Using that and __autoload (assuming PHP), then the Site devs don't really have to worry about where the module is located to use it.