I have been programming in PHP for about 15 years, but have always worked alone coding from scratch, and never 'truely' made the switch to fully fledged OO code as is it generally considered. I've made a lot of use of objects, and have hand written a couple of frameworks from scratch that divide logic from presentation and simplify a lot of common tasks, but I've been using over-filled objects in a very procedural manner, and none of my code is particularly testable.

It's taken me a while to get my head around the idea of routing via a front controller to an action in a page controller, rather than just using a different pages with if's and elses to do different things. The Phalcon documentation is the first time things are finally starting to sink in.

I've been putting off rewriting my online browser-based game for years and years, partly because it's such a huge task, but partly because I didn't see the point in converting to 'modern' coding styles until I had a good enough idea. After all, when what I have previously written works perfectly well, changing just because people 'say' it's better doesn't make sense.

Anyway... The Application I want to rewrite is non-standard from a structural point of view. There's a hell of a lot more to a browser game than a blog or shopping cart, but I've made the decision on the 'basic' folder structure I want to go with.

  • Controllers
  • Views
  • Library [or Engine]
  • Repositories
  • Entities

It's taken me a while to settle on Library, and Engine might work just as well, but I'm not interested in going OO for the sake of it, so the traditional MVC with either a fat Model or a fat controller doesn't do it for me. The DDD multi-module file structure from the phalcon "mvc-master" examples seems most appropriate to me. But 'Services' didn't feel right to describe what would essentially hold the bulk of the game logic.

The next issue that I'm trying to decide is how to structure the modules. There is not one application and one database, there are multiple databases in use. One for each game world/environment/server (whatever you want to call them) and one for the website. I don't want a different folder of code for each game instance, but I do want at least one layer of seperation between a development/beta test environment and the live games.

This is my current thought, but I'm starting to doubt it when I see how 'modules' are generally used in phalcon apps. define.php is basically the module array that will be used later in the bootstrap in register.php, but provides me with an easy way of building module specific routes prior to registering the modules. That way the appropriate game database can be pulled from the route and used during initialisation.

  • code/
    • config/
      • modules/
        • define.php
        • register.php
      • services.php
    • game/
      • development/
        • config/
          • config.php
          • routing.php
        • controllers/
        • entities/
        • library/
        • repositories/
        • views/
        • Module.php
      • live/
        • config/
          • config.php
          • routing.php
        • controllers/
        • entities/
        • library/
        • repositories/
        • views/
        • Module.php
    • website/
        • config/
          • config.php
          • routing.php
        • controllers/
        • entities/
        • library/
        • repositories/
        • views/
        • Module.php
  • vendor/
  • www/

Are 'modules' the right way to do this?