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

larger project - directory structure

Hi, I'm new to Phalcon. I'm porting my app from my custom framework (i know...) to Phalcon. I will have about 50+ models and controllers with possibly custom event managers, model managers, etc.

How would you structure your folders? I rather not have this:

  • app
    • config
    • library
    • models (with 50+ files)
    • controllers (with 50+ files)
    • eventmanagers (with 50+ files)
    • modelmanagers (with 50+ files)
    • forms (with 50+ files)
    • etc etc Like this when I want to refactor something, I need to dig in different directories to find all the related classes of a model.

Instead how about this:

  • app
    • config
    • library
    • entities
      • Base
        • Model (extends \Phalcon\Model)
        • Controller (extends \Phalcon\Controller)
        • EventManager (extends \Phalcon\EventManager)
        • ModelManager (extends \Phalcon\ModelManager)
      • Product
        • Model (extends Base/Model)
        • Controller (extends Base/Contoller)
        • EventManager (extends Base/EventManager)
        • ModelManager (extends Base/ModelManager)
      • Seller
        • Model (extends Base/Model)
        • Controller (extends Base/Contoller)
        • EventManager (extends Base/EventManager)
        • ModelManager (extends Base/ModelManager)

This way e.g. when I want to change something that effects all model, I just change that in the entities/Base/Model. When I wanto to refactor the Product I change the related files only in that directory. If an entity (e.g. Seller) has some more complex logic and maybe needs some helper classes, they can all be found in the entities/Seller folder.

Any opinion/advice/criticism is appreciated.

I think better to switch to multi-module where you will try to make a proper modules dedicated for each part of application. This way you can have good directory structure and inside of every module directories like Model Controller, etc. Not sure for what you need ModelManager, you mean a class which consists all methods to findXYZ? Then it's called Repository.

edited Jun '18

Thanks, I will look into multi-module.

ModelManager: yes, a Repository. Im still reading the Phalcon docs, but as a first glance the Phalcon Model Manager seemed like a Repository, (or a DataMapper)? https://docs.phalcon.io/ja/3.3/api/Phalcon_Mvc_Model_Manager

Perhaps it deserves a separate discussion, but if you don't mind answering (or linking to a known good article): Is there a common repository and datamapper strategy/pattern with Phalcon? (My edit: this tells me there is no Phalcon-Specific repository thing)

Model manager is a service which handles all model related stuff, in 99% cases you don't need to create your own class like that.

Phalcon doesn't use datamapper pattern, it uses active record.

So repository classes are just your own thing to do pretty much if you want to have dedicated class with all methods to do all finding, so yes, there is no phalcon-specific repository thing, i think it's just better to put all complex queries to separated class.

I suggest to create App\Phalcon folder with same structure as phalcon and put there proxy files to phalcon fw. It's much easier to maintain on phalcon version update.

Example:

<?php

namespace App\Phalcon\Mvc;

class Model extends \Phalcon\Mvc\Model
{
}

This link should help with the multi-domain

https://github.com/phalcon/mvc/tree/master/multiple

Thanks, I will look into multi-module.

ModelManager: yes, a Repository. Im still reading the Phalcon docs, but as a first glance the Phalcon Model Manager seemed like a Repository, (or a DataMapper)? https://docs.phalcon.io/ja/3.3/api/Phalcon_Mvc_Model_Manager

Perhaps it deserves a separate discussion, but if you don't mind answering (or linking to a known good article): Is there a common repository and datamapper strategy/pattern with Phalcon? (My edit: this tells me there is no Phalcon-Specific repository thing)