Question

What It Is

Here is what I’ve done so far:

• core/
  • controllers/ (contains the controllers used by the app)
  • models/ (contains the models used by the app)
  • views/ (contains the views used by the app)
  • base_controller.php (the controller every other extend)
  • base_model.php (the model every other extend)
• vendors/
  • phprouter/ (a simple router class)
  • pimple/ (a simple DI container class)
• configuration.php (contains all the app configuration)
• index.php (includes the configuration, vendors, base model, base controller, sets the DI container up and route the request)

See the code here: http://pastebin.com/pxUpUvv6
Please note that the given code is just an example, therefore the controllers, models, views aren’t in place yet. Also, it may be buggy—as untested—, but it doesn’t matter right now.

Request Flow

1. The client requests index.php.
2. The configuration, vendors, base controller, base model are included.
3. The DI container and the dependencies are initialized, we can now inject them anywhere.
4. We map controllers to URL and the router does its job.
5. The controller is fetched (although this is not in the example code, as noted above).
   • We do some stuff.
   • The method then calls ::call_model(), which includes the corresponding model from core/models/, and then calls the same method we’re using from the model class corresponding.
6. The model is fetched.
   • More stuff.
   • The model then calls ::call_view()‘, which includes the corresponding view from core/views/.
7. The view is fetched and render the page to the client.

FYI: Corresponding

Examples of controller, model, view which correspond:

• Controller Controller_Products::list() at core/controllers/Controller_Products.php
• Model Model_Products::list() as core/models/Model_Products.php
• View at core/views/Model_Products_list.php

Issues Being Faced

Actually, I feel a bit uncomfortable with this structure. Dunno, it seems to be far from scalable, modulable…

1. Does only the basic folder structure—core{, /controllers, /models/, /views}, vendors at the root—looks good to you?
2. I feel like I should get __autoload() outside of index.php, which seems a little too big to me. If so, what about DI container?
3. Maybe if I get to needing more than two external library, it should be better not to have them included one by one, manually? But how?
4. Putting all the configuration in a file configuration.php at the root looks to me like old-fashioned PHP4. Thanks to the power of Pimple, I could embed this configuration directly into it but yet, where?
5. I think the way I handle ::call_model() (core/base_controller.php) and ::call_view() (core/base_model.php) is a bit awkward. Would you agree? What’d be a simplified way to redo the whole thing?
6. Considering all my issues, would it eventually be better for me to use a framework as Symfony?

If something isn’t clear, feel free to ask.
Thanks.

Answer 1

1. Yes.
2. You can use autoload and DI container together. There is example, how autoload can be used with naming convention. I recommend to use spl_autoload.
3. With autoload you can remove all (or almost all) includes.
4. In index.php, I guess.
5. Yes, it’s wrong way. First of all, try to not use static methods. Also, models should have methods with descriptive names, not just ‘call me and I will do all what I can’. It’s more complex problem – you need to understand how Controller and Model should do their cooperation. As variant, read some books. Controller should call methods of Model, to get data for some situation. Model it’s not just place for code of controller. Different controllers can use different models. Models too can use another models.
6. Answer to this question can not be objective 🙂