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. css/ js/ images/ ... index.php -> Application's entry point. src/ -> UI layer rules. Application/ Controller/ View/ ViewModel/ 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:
- To move the
- To move the
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
I really find the two steps a very good idea, because, as I see it, both folders contain resources related to the structure from
So, instead of having something like this:
a structure like the following seems to be much better:
But, after I studied many web frameworks, I realised that all of them keep the two folders (
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?
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:
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.