php - with - Reasons for not having a compact structure of an MVC application?

php mvc tutorial step by step (2)

Classify your code

The only thing that I would recommend is to keep the namespace equal to the directory structure to keep autoloading simple. From there, the language does not care how code is organised. The two limitations are namespaces and directories: these are hierarchical. So that determines that you can only classify code in a hierarchical structure.

The actual problem is that hierarchical classification is a problem in itself. Objects can be classified in many ways. Fortunately PHP is agnostic towards classification, so why can't humans be the same? Because we actually think about code and objects. We search for them, use them, nurture them. It's just a matter of personal experience and taste, what are your strongest associations with certain object behaviours?

There is one extra thing to consider: "Hell is other people."

Keeping your classification compatible with others, like that of the Symphony framework, will come in handy once your code starts to depend on that particular framework. Or the classification scheme of others can be something you are not willing to subject to.

Either way, there is no reason not to do what you want. If, later on, you change your mind, at least you'll know for yourself why you changed it and you will learn from it.

In a web MVC project, I have the following structure:

mymvc/                      -> Project root.
    public/                 -> Document root. The only one folder accessible from web.
        assets              -> Client-side assets. NOT ONLY for global themes and libraries, BUT ALSO for each specific "view" controlled by the "src/Application" components.
        index.php           -> Application's entry point.
    src/                    -> UI layer rules.
        Dispatcher/         -> Application dispatching - route matching, dispatching to the specified controller, etc.
        ...                 -> Other classes used by the components in the "src/Application" folder.
    templates/              -> Layout and template files.

Note: All domain model components (entities, repositories, data mappers, services, etc) reside in a folder outside of mymvc directory, so that they can be accessible by any other application, too.

I thought - a lot, actually - about doing the following two steps:

  1. To move the templates directory to src/Application folder.
  2. To move the assets directory to src/Application, to create an alias /assets/ in the web server (Apache) configuration - pointing to the moved folder, and to allow full access from the external world to it.

The globally used assets - like css themes, or js libraries codes, or background images, or etc - could still remain located in the public directory - obviously not in a folder named or aliased assets.

I really find the two steps a very good idea, because, as I see it, both folders contain resources related to the structure from src/Application. So, instead of having something like this:

  • src/Application/Controller/AboutUs.php
  • public/assets/js/AboutUs.js
  • templates/AboutUs/[multiple-layout-and-template-files],

a structure like the following seems to be much better:

  • src/Application/Controller/AboutUs.php
  • src/Application/assets/js/AboutUs.js
  • src/Application/templates/AboutUs/[multiple-layout-and-template-files],

But, after I studied many web frameworks, I realised that all of them keep the two folders (templates and assets) completely separated from the application folder.

So I'd like to ask: Are there any specific reasons, why my proposed moving of the two directories can not, or should not be done?

Thank you.

In my opinion everyone could use a structure that suits him/her best.

I've been working with CodeIgniter a lot the past years and have been doing some juggling with files and folders myself. At the end I think I have the structure as I like it :)

For the application folder I, mostly, just stick with the recommended (basic) structure as in their manual and tutorials.

It looks like this:

- versionX
    - application
        - config
        - controllers
            - assets // Folder to keep asset specific controllers
                js.php  // These controllers are bundling all resources and returning it as css, js or image file. Images can be cropped etc by params in url. Framework routes urls as to the css.php controller etc
            documents.php // normal controller files
        - core // core (controller) files from which controllers can extend
        - helpers // Holds files with functions that you can use everywhere in the app.
        - libraries // Holds library files and folders
        - models // holds files with all DB logic (one file per DB table in my case, join tables not included)
    - public
        - css
        - js
            - components // javascript files for specific (large) page element(s)
            - controllers // one js file per controller for controller specific js code
            - resources // all libraries from 3rd party (Bootstrap, jQuery, ...)
        - uploads // user generated content (folder divided per file use/ origin)
    - themes
        - blueSky
            - views
                - layouts // app level views
                    - partials // app level partials (main navs, footers, ...)
                - documents // a folder per controller
                    - modals // modals used at document controller
                    - partials
                        _form.php // for adding and editing documents
                        _drawer.php // submenu for document controller
                - users

I hope this gives you some idea on how I do it. But you realy should do what you like the most. Nothing worse than having to browse through something you don't like.