We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. Beginners

Phalcon directory structure best practice - MVC structure

Hello, Fellow phalcon developers. Sorry for such a beginner question. I am new to phalcon framework and try to find the best way to organize the source code structure.

The project I am working on is a large scale e-commerce site. There are many components and I am not sure what is the best way to organize the code in Phalcon MVC.

Option 1: Should I organized them in in logical group first, then within each logical group, add MVC structure?

Option2: Or Should I keep MVC structure as top, then add logical group within each MVC structure?

Sample for Option1:

App/
  Controllers/
    User/
    Admin/

  Models/
    User/
    Seller/

  Views/
    User/
    Seller/

(FYI, in the most samples I've seen, I never seen anyone creating a sub-folder within controllers. I am not sure if this is because of Phalcon limitadtion)

Sample for Option2:

App/
  User/
    Controllers/
    Models/
    Views/

  Admin/
    Controllers/
    Models/
    Views/

I personally prefer option1, because sometime, the code may not have a clear boundary of which group it falls into, so I can put them in parent location or create another general directory. For option2, one of reason I don't prefere is because for developer, when he try to find a code and if the group is not very clear, then once again, it will be hard to locate.

Thanks for your feedback.



784

Hey, go for option 2 (multi module) where each directory in apps/ must have its own MVC structure.

Though you can always mix sub controller on each module. Refer to link below.

https://docs.phalcon.io/en/latest/reference/applications.html



6.0k
edited Feb '17

Hi, I've got some experience in e-commorce using Phalcon so I suggest you this structure (I've been working with Front-end-man and there wasn't collisions)

/app
    /backend -> admin's part
        /controllers
        /models
        /views
        Module.php -> services for backend like own MySQL connection
    /frontend -> user's part
        /controllers
        /models
        /views
        Module.php -> services for frontend like own MySQL connection
    /library ->Access Control List (ACL) and some extra classes, mpdf library or smth like that
    /config -> settings of this app, db password etc.
    /logs -> it's good to log errors etc.


1.7k
edited Feb '17

Thanks for the comments. I think my choice of using user and admin wasn't really good example. I agree with you all, using option 2 when there are clear distinction like front-end (user) vs back-end (admin). However, I want to further distinguish features in different group under the front-end. Here's example. (I kept multi module setting as everyone suggested for large grouping).

Sample Option1 (Separate MVC for multi modules + Sub-features are grouped further within each MVC in each module)

App/
  front-end/
      Controllers/
          user/
          seller/
          product/
      Models/
          user/
          seller/
          product/
      Views/
          user/
          seller/
          product/

  back-end/
      Controllers/
      Models/
      Views/

  lib/
  config/

Sample Option2 (Separate MVC for multi modules + Separate MVC within each sub-group)

App/
  front-end/
      user/
          Controllers/
          Models/
          Views/
      seller/
          Controllers/
          Models/
          Views/
      product/
          Controllers/
          Models/
          Views/

  back-end/
    Controllers/
    Models/
    Views/

  lib/
  config/

Once again, thank you for your feedback in advance.



6.0k

Sample Option1 is more intuitive for me