Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

There are a two main codebase structures that I have seen when it comes to MVC frameworks. The problem is that they both seem to have an organisational bug that goes with them.

Standard MVC

/controller
/model
/view

Problem: No separation of related components (forum, blog, user, etc..)

Modular MVC

/blog
    /controller
    /model
    /view
/user
    /controller
    /model
    /view
/forum
    /controller
    /model
    /view

Picking the module-based system leaves you with a problem.

  • Long names (Forum_Model_Forum = forum/model/forum.php) (Like Zend)
  • File system searches using is_file() to find which folder has the forum model? (Like Kohana)

Are their any other MVC structures that work well when trying to separate different modules? Are there benefits from these structures that I'm missing?

share|improve this question

closed as not constructive by gnat, Martijn Pieters, ChrisF Jan 12 '13 at 22:22

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
I would also like to add that I want a structure that is PSR-0 compliant so I can also use libraries like Zend and Doctrine if needed. –  Xeoncross Jul 16 '11 at 14:42
add comment

8 Answers

Try:

/blog 
    /controller
    /view
/user
   /controller
    /view 
/forum
    /controller
    /view
/model
    User
    BlogPost
    Comment
    ....

Your models are the heart of your application. You should design and code them as a standalone package. The controllers are just clients of your model, that happen to translate user activity into actions for your model. A view is just one particular way of displaying data from your model. If your application grows, you could go even further in separating clients from the model:

WebClient
    /blog 
        /controller
        /view
    /user
       /controller
        /view 
    /forum
        /controller
        /view
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment
    ....

This should make it obvious that you can have multiple clients, that all in one way or another, interact with a single model.

share|improve this answer
    
+1 because I totally agree with your explanation of the MVC components and how they should work. However, the point of a module is that you can import modules created by other users so having the models outside the module path makes it less "drag-and-drop". However, your method makes great sense for applications that make no use of external plugins or modules. –  Xeoncross Jul 17 '11 at 13:57
    
@Xeoncross that's true, I haven't really taken reusability into account here. If that's a requirement, you could indeed go one step further and have for example a 'User' module that groups the User model with it's controller, and a Blog module that groups the BlogPost and Comment model with it's controllers. As always: it depends on context :-) –  Mathias Verraes Jul 17 '11 at 14:21
add comment

I've given this same answer a few times lately, but I do believe it's valid.

The best example of a modular MVC app I've ever seen is Orchard CMS. I really would suggest looking at that source for some cues.

share|improve this answer
    
So the structure you recomend is just actually a dual module directory? Orchard seems to have a "Core" folder with system modules and a "Module" folder with user modules. Though, I don't program in .NET so I'm not sure. –  Xeoncross May 9 '11 at 19:01
add comment

Problem: Long names (Forum_Model_Forum)

Systematic naming of the classes helps to avoid naming conflicts between components. Long naming of classes is not likely to impose severe performance penalties. I find this naming scheme rather helpful when coding because it is easy to see what comes from where.

file system searches (which folder has the forum model?).

This very much depends on how the system has been implemented, but the structure of the file system usually follows a convention which allows immediate access to the correct component without extensive file system searches.

Here is an example, suppose the forum component is to be used:

Info:

  • Component-name: forum
  • Controller-name: index

    $controller_path = BASEDIR . 'module/' . $component_name . '/controller/' . $controller_name . '.php';

Also it is important to note that there are literally hundreds of file system queries when booting a typical website, so adding some is not going to hurt.

share|improve this answer
    
Truly, back ends aren't like client-side apps that need to start up quickly, they can take the time needed to configure the run time properly. Good point. –  Patrick Hughes Jul 16 '11 at 16:18
add comment

;)

I found the best structure for a MVC/HMVC Framework combined. For the main you need to use base controllers/models/views... but for the individual components of course modules...

So in my MVC/HMVC framework structure looks like this:

/application
  controllers/
  models/
  views/
  modules/
    blog/
      controllers/
      models/
      views/ 
    user/
      controllers/
      models/
      views/
    forum/
      controllers/
      models/
      views/

Also if i need i add in modules libraries, i18n or helpers.

Naming convention is easy, for controllers and models i add suffix _Controller and _Model. For controllers and models from the modules i also add a prefix with module name, for ex. controller Profile in module User will be named as User_Profile_Controller.

So it's verry easy and fast to find what you need for.

share|improve this answer
add comment

I have work with websites that started with the first "Standard MVC", but eventually, become the "Modular MVC".

If you are doing a small website, and don't have much experience, you may want to start with the "Standard MVC". If you already know the website is going to be very complex and big, then, you'll have to get used to the "Modular MVC", it will be a little difficult at start, but, eventually, you'll get used to it.

share|improve this answer
add comment

I am actually working on a framework myself and use a combination of both module based and free-form directory structure. My default structure for site code using the framework is:

/Configuration (stored a bunch ini files for security related information like passwords)
/Functions (stores file(s) with standard procedural functions)
/Libraries (general use classes)
/Models (all models go here)
/Modules (each module refers to one controller
/Modules/Site (controller class store in this folder if there is a controller)
/Modules/Site/Views (views for the controller)

You can also have a module folder that does not relate to a controller and there is one by default call Core that is used to store site wide templates like the header and footer. This to me gives the best of both worlds. You can easily know where the controller is since there is one one controller per folder but for classes like models you don't need to search for where the files are as they are under one directory (that also keeps the names of the models cleaner).

The way I load files is a little different as I allow the user to configure the different directories on where classes could be so I parse the directories initially and store all the class file locations in a json file and then use that for quick look up for all other requests (even though I am looking at ways to improve this).

share|improve this answer
add comment
up vote 0 down vote accepted

The answer to this has been dictated by the PSR-0 Proposal which all large systems are starting to adapt, or have adopted now.

The structure is:

\Doctrine\Common\IsolatedClassLoader => /Doctrine/Common/IsolatedClassLoader.php
\Symfony\Core\Request => /Symfony/Core/Request.php
\Zend\Acl => /Zend/Acl.php
\Zend\Mail\Message => /Zend/Mail/Message.php

This means that there is nothing you can do to fix long file names:

$controller = new \Blog\Controller\Archive => /Blog/Controller/Archive.php

/Blog
    /Controller
        Archive.php
    /Model
    /View
/User
    /Controller
    /Model
    /View
/Forum
    /Controller
    /Model
    /View

This also means you have to use dumb mixed-case files instead of all lowercase (if you don't third-party libraries will not work).

share|improve this answer
add comment

Mathiases solution makes great sense And using his folder structure does not prevent having pluggable content, for example adding an independent /gallery/ could look like this

WebClient
    /blog 
        /controller
        /view
    /user (uses /model/User/)
       /controller
        /view 
    /forum
        /controller
        /view
    /gallery
        /controller
        /view
        /model
CommandLineClient
    delete_spam_posts_script
RestApiClient

/model
    User
    BlogPost
    Comment

Now we have a shared "model" and independent ones if necessary

share|improve this answer
add comment

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