So, I have different aspects of the app: front-end ui module, output generation (pdf reports, etc), console commands and workers.
Using the standard examples, let’s say we have Book and Author models. These would all reside in /app/models/.
Now, the issue is that there is tons of code that need to go into these models that relate only to the ui. There’s tons that relate only to the output generation, etc.
So to organise this I see a few options:
1. Put all the code in the common models.
This is a bad idea IMO because it just creates a bunch of noise for when you are working on a specific aspect of the app. Much of the code does not relate to what you are doing.
2. Extend the models in each module.
This seems like the obvious one. Have all the common relations and code in the common models, and then have child classes (app/modules/ui/models/Book extends app/models/Book) contain the specific code relating to to that module.
The issue with this is that the relations will return the wrong class: app/modules/ui/models/Book would have a relation author that returns app/models/Author instead of app/modules/ui/models/Author
Or, I have to re-implement all the relations in the child classes, and that’s really not DRY.
3. Use traits
This one seems wrong to me, but it does allow me to organise the code a bit. Basically, instead of using child classes that cause the aforementioned issues with relations, I would organise the "child class" code into traits instead, which would be used by the common models.
So far I am leaning towards #3, but I really feel #2 is the correct solution but I don’t know how to do that without repeating all the relations (and this app has a lot).
One of the issues I have with Yii2 is the relation management. Each model will need it’s own Query class for the IDE to properly be able to understand that it’s a Book being returned by the Query, not an ActiveRecord. So far I’ve automated this, but having to add yet more Query classes would seem bloated.