I am creating a php project with / models (entity classes), / DAO (on which I use this pattern for bd access), / controllers, / services, etc.
As it is an educational project, using a traditional OOP approach, I find myself in the common problem of As a reading / writing mapping of my domain model? But going to my question: If I had for example a law office, on which each of these is charged, and have their case records (issues) of each client. If I said: It's a class it belongs to - > client, lawyer. I can make composition:
class Issue {
// Instancia del abogado
protected $lawyer;
// Instancia del cliente
protected $customer;
protected $id;
protected $title; //etc...
// getters y setters...
}
The problem with this comes when I want to store. I will not store Issue with those two other objects that it contains, because they are supposed to have a different lifetime , it is not the class that owns the rest, and there is a proper api to store each one. Or it could be exceptionally that when saving are only the own data and not the components?
An alternative to this, and explained in this thread, is: entities keep them simple, without compositions and only data, at best, references to the association. And then to join an accessory class:
class IssueReport {
// Instancia del abogado
protected $lawyer;
// Instancia del cliente
protected $customer;
// Instancia del caso (una clase sin composiciones)
protected $issue;
// getters y setters...
}
With what I think I would be making a very valid form of association.
That said, which approach, (or other), would be healthier for these cases, in which practically I use SQL to store my classes?