Within MVC, what directory structure would other developers expect?

Question

Typically, MVC frames have a structure that looks something like this:

/models /views /controllers /utils 

However, in the web application suite, I decided that combining all the models, views, and controllers together probably would not be the best for clarity, unless I consider the system as a single application, rather than a collection of applications. However, some things bind each “application” together as a concept of users and user roles.

So, I have three possible solutions:

(1) Do what I really don't want to do, and keep each model, view, and controller together, no matter which application it belongs to. This refers to the package as a single application, since they are connected to each other by several common threads, including users.

(2) Group the code using the application.

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

(3) Group the code by type, allowing you to use the utility code for all applications.

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

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

Answer 1

2) seems to be your best option, assuming you want to split applications. You may also have a “/ common” folder at the “/ app #” level for shared resources in all applications ... for example, a common utility class or something else.

Answer 2

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

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

Answer 3

If your applications exchange data, it may be wise for me to combine models.

However, for views and controllers, it probably makes sense to keep them separate, as I assume they have separate business logic and presentations.

In addition, if your applications are stored separately in version control (you use version control, right? :), which makes it impossible to implement the first or third version.

So, having considered everything, I would probably separate the applications at the top level, as in your second example.

Answer 4

I usually group code by function, so in your case, grouping by application will make the most sense to me. The reason is that if I want to work on a specific function, I will not need to search for three separate folders that look for the components I need. If you group a high-level function, you know that all you need is together.