Under an MVC framework, which directory structure

Question

Generally, MVC frameeworks have a structure that looks something like:

/models
/views
/controllers
/utils

However, in a web application suite, I've decided that clumping all models, views, and controllers together probably wouldn't be the best for clarity, unless I treated the system as one application instead of an application suite. However, some things tie every "application" together, like the notion of users and user roles.

So I have three possible solutions:

(1) Do what I don't really want to do, and keep every model, view, and controller together, regardless of which app it belongs to. This is treating the suite as a single application, since they are tied together by several common threads, including users.

(2) Group the code by application.

/app1
    /models
    /views
    /controllers
    /utils
/app2
    /models
    /views
    /controllers
    /utils

(3) Group the code by type, letting utility code be shared among all of the applications.

/models
    /app1
    /app2
/views
    /app1
    /app2
/controllers
    /app1
    /app2
/utils

Is there an option I missed? What would be the most logical scheme for future developers? I personally prefer 2 and 3, but perhaps most people would expect 1.

Answer 1

2 is a good start. You should consider having a common folder in which you can store any common models, views and utils used by all apps in the application suite.

/app1
   /models
   /views
   /controllers
   /utils
/app2
   /models
   /views
   /controllers
   /utils
/common
   /models
   /views
   /utils

Answer 2

I usually group code by feature, so in your case grouping by application would make the most sense to me. The reason is that if I want to work on a particular feature, I shouldn't have to search through three separate folders looking for the components I need. If you group by the high level feature you know everything you need is together.

Answer 3

If your apps share data, it could make sense (to me) to group the models together.

However, for the views and controllers it probably makes more sense to keep them separate, since I'm assuming they have separate business logic and presentations.

Further, if your apps are kept separately in version control (you are using version control, right? :), that makes the first or third option difficult to implement.

So all things considered, I'd probably separate the apps at the top level, as in your second example.

Answer 4

It seems like 2) would be your best option, assuming you want some separation of applications. You could also have a "/common" folder at the "/app#" level for shared resources across all applications... like a shared utility class or whatever.