Stiamo progettando un importante refactoring nel codebase del mio sistema aziendale. Uno dei punti refactoring è la (effettiva) definizione del modello di logica di business / dominio. In questo momento, ogni repository della base di codice recupererà solo ogni possibile parte di dati relativi all'entità, e per "ottimizzarlo", tutto verrà recuperato negli array piuttosto che negli oggetti (tecnicamente, hashmap di valori-chiave, ma in PHP essi ") chiamato array).
Ora vorrei introdurre l'uso effettivo degli oggetti del modello che incapsulano la logica aziendale (chiamando metodi come businessObject.canTransitionToNextProcessPhase() anziché eseguire un gruppo di if/else in un controller, con conseguente 0 leggibilità.
Per la prima parte di questo design, sto identificando quali dati relazionali sono must-load per ogni entità. Può essere facilmente identificato quando un'entità è dipendente. Ad esempio: un Entry dovrebbe sempre caricare Category e User (autore). Tuttavia, quando recuperi un User , non devi necessariamente caricare tutte le voci, i tuoi amici, Etc.
Ora, in alcuni casi particolari , quando carichi User , potresti voler caricare anche tutti Entries . Come progettare un pattern di repository che ti permetta di caricare i dati relazionali in quei casi particolari?
Ad esempio, prendi il metodo UserRepository@getById(int) :
Il metodo dovrebbe ricevere parametri di opzione che consentono di decidere se caricare relazioni aggiuntive diverse da quelle predefinite? (Ad esempio: ContactInfo è il valore predefinito, l'elenco di Entries è aggiuntivo).
Dovrebbe invece essere configato in un metodo concatenabile come repo.alsoLoad('entries').getById(id) ? (comunque questo sembra replicare l'API di ORM, penso).
Si noti che l'obiettivo di questo modello di schema di repository non è solo un livello che copre l'ORM senza necessità. I metodi recupereranno i dati in base ai casi di utilizzo aziendale: getAllInvoicesFromCurrentCycle() anziché getAll(hashamp /* with 5 key/values to be passed directly to the ORM's where clause*/) poiché quest'ultimo non fornisce alcun vantaggio (né leggibilità) (potrebbe anche essere utile utilizzare direttamente l'ORM).
Aggiornerò la domanda se sono necessari ulteriori chiarimenti.