Create-and-forget works fine — until you have to come back to it a year from when you last touched it and try to update it. With Yii2, Laravel, and Symfony, I’ve taken two basic approaches. The actual names may vary depending on the framework, but the structure remains. They are:
Object-centered approach
Within the Models, Controllers, and Views directories, there are subdirectories for specific groupings of tables. (Yes, it remains that there is one model and controller per table, but those models and controllers, with their views, are organized into a hierarchy.) Right now, my structure — very abbreviated for the purposes of illustration, with pivot/join tables left out for brevity — would look something like:
Entities Subdirectory
Entities
EntityCategories (lookup table)
EntityRoles (lookup table)
EntitySources
EntityTypes (lookup table)
EntityLocations
EntityPhones
HealthCare Subdirectory
HealthCareProviders (belongs to Entities)
HealthCareProviderTypes (lookup table)
HealthCareAllergies
HealthCareAppointments
HealthCareDiagnoses
HealthCareImmunizations
HealthCareImmunizationTypes (Lookup table)
HealthCareMedications
HealthCareTests
HealthCareTestPanels (Lookup table)
HealthCareTestPanelTests
HealthCareTestResults
HealthCareTestResultRatings (lookup table)
HealthCareTreatmentCenters (belongs to Entities)
I could go on for about 15 more subdirectories, but this should give you the idea. These same subdirectories repeat under the directories for Models, for Controllers, and for Views. Sure, you could dump all this in one directory and use search within PhpStorm — as long as you can remember the name to search for. If you carefully name each class, as I have done in my example above, it’s fairly simple, but if you have to pick up behind someone else, you’re lost.
Module Approach
With this approach, a “module” is created for each of the subdirectory topics like I listed above. So for instance, there would be an Entities module that has directories within for its models, controllers, and views. The module, in effect, becomes an “applet” — but, it is very much a participating member of the entire webapp. So, for instance, there is no problem with the HealthCareProviders model reaching across to form a belongs-to relationship with Entities within the Entities module. It may be that this approach can be achieved by Cake’s concept of plugins, but the absolute paucity of documentation gives little to no guidance or support for going to that direction. I’m also not sure if the inter-plugin relationships in Cake would work all that well.
In my experience, the development process begins with the object-centered approach and ends up modular. The issue is that the major, mature frameworks allow both.
I guess one of the things that really perturbs me is the immaturity of Cake’s documentation and flexibility for the many approaches that developers take. When I compare at Yii2 and Laravel, I can really see that Yii is an older much more mature framework. Laravel is much newer, and its relative immaturity really shows. (Having to specify the route for every controller action? Yikes! Thank God they finally created resource routing that diminishes that somewhat, but compare that to Yii where you never have to specify routes. The framework figures it all out.) CakePHP is as old if not older than Yii, yet lacks the maturity, flexibility, and documentation that Yii has.
Speaking of documentation, you want to bake a model in Cake? It’s no where as easy as Gii in Yii where you can just do it all in a GUI, but you do have Bake. Take a look at the instructions for baking a model. If you follow the instructions, you just enter cake bake with the appropriate allowance for directories. Just cake bake , nothing else. I figured out that you must have to enter something like the table name, the model name, but what? It’s nowhere in the documentation, at least that I could find. Procedures for developing a plugin? Forget it. It’s time for CakePHP to grow up and have the maturity that it should.
Larry E. Lutz