Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Under an MVC framework, which directory structure would be expected by other developers?

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.

like image 370
Thomas Owens Avatar asked Oct 07 '08 13:10

Thomas Owens


4 Answers

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
like image 151
Szymon Rozga Avatar answered Nov 14 '22 23:11

Szymon Rozga


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.

like image 23
Rodger Cooley Avatar answered Nov 14 '22 23:11

Rodger Cooley


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.

like image 30
Bill the Lizard Avatar answered Nov 15 '22 01:11

Bill the Lizard


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.

like image 34
Adam Bellaire Avatar answered Nov 15 '22 00:11

Adam Bellaire