I am trying to do an ORM many_many relations between Clients and Contacts and I am not entirely sure where I should put the establishing and breaking the relationships in. I keep thinking it supposed to go into Controller as oppose to Model.
Its more of a design question, and as to ORM's there are two schools of thought.
One that says the ORM provides the model (and the model logic), and since the model is used in the controller, that is where you make/break relations. The other sees the ORM as a data access layer, and still uses model classes to abstract all data operations away from the controller.
The first is easier, but can lead to lack of DRY, the second introduces two types of model classes which can be confusing, but all data operations are DRY.
I personally use (and advocate) the second. It has proven to be a huge time saver when there are schema changes, as everything is centralized in the model, not scattered over all controllers (imagine you change that relation to a one-2-many?). It also allows you to swap ORM with DB calls in case of performance issues without impact to the rest of the application (we even swapped ORM by REST once, to split frontend and backend into two different tiers).
It also allows you to approach model design from a more functional level. In this case, I can imagine you can have contacts without a client, so two models might be handy, but in case it would have been a one-2-many, it would have made sense to only have a Clients model, and give that methods like $client->add_contact() / $client->delete_contact().
We namespace everything, so application models live in \Model (or \module\Model), ORM models live in \Model\Orm (or \module\Model\Orm). It makes the distinction between the two clear in your code.
Donate
