Sto utilizzando il leggero PHP Fat-Free Framework come base per formare una semplice app basata su MVC con filosofia DDD per il modello strato. Sono consapevole del fatto che DDD è la soluzione più adatta o aziendale e che applicare DDD a semplici app per lo più basate sui dati è un po 'eccessivo, ma ci sono alcuni concetti in DDD che trovo allettanti (come il pattern Repository, la logica di business in Entità, ecc.) Che mi piacerebbe applicare alla mia app.
Fat-Free Faramework ha una classe Base che rappresenta l'applicazione (un Singleton) e l'istanza di Base contiene molti strumenti utili e un registro di variabili globali (l'alveare) che viene usato, tra le altre cose, per i dati di configurazione.
Mentre scrivo la mia app, mi trovo a utilizzare molti strumenti di classe Base all'interno delle classi nel livello Model e sono un po 'confuso da come fare riferimento all'istanza Base in quelle classi. Chiaro semplicemente Base: instance () all'interno delle classi del modello o lo inietto tramite il costruttore come dipendenza? L'iniezione delle dipendenze sembra il modo corretto per farlo, ma dal momento che la maggior parte dell'app dipende da questo, l'intero riferimento che passa attraverso il costruttore non sembra necessario. Inoltre, come passare per un esempio di dati di configurazione del database alle classi di persistenza dei dati che sono archiviate nell'alveare? Dovrebbe essere passato dai Controllori durante l'istanziazione dei Repository o richiamato direttamente dal Repository (o dal Data Mapper)? Sto cercando un modo che non mi ritorni contro, quindi sto cercando qualche intuizione o consiglio su questo.
La seconda parte del mio problema è che sto cercando di scrivere la mia app in modo che ogni Entità e logica aziendale ad essa correlata sia configurabile dalla classe Entity. Questa è un'idea ispirata da Sails.js Sto ancora testando, ma per un esempio, ho un metodo getProperties () che restituisce una matrice di dati di configurazione definiti dall'utente per ogni proprietà Entity, ad esempio:
'title' => array(
'type' => 'text',
'minLength' => 30,
...
)
o per associazioni:
'children' => array(
'entity' => 'ChildClass',
'relation' => 'oneToMany'
)
Potrebbe sembrare un po 'controverso, ma ho testato la funzionalità di business logic e finora funziona correttamente per me, e il codice client comunica con le entità tramite i normali metodi get / set / other. L'idea alla base di tale configurazione è quella di essere in grado di generare automaticamente l'interfaccia di scaffolding / amministrazione per ogni Entità e configurare Data Mapper e Repository basati sul metodo getProperties () dell'entità correlata.
Ciò che mi infastidisce ora è che se voglio avere un luogo in cui esistono questi dati di configurazione, dovrei inserire alcune logiche di dominio non business nell'entità, come un eccezionale nome della tabella del database, se un campo richiede o meno un editor di testo RTF, se una casella di controllo è selezionata per impostazione predefinita, un determinato campo utilizzato come identità di stampa di un'entità nell'interfaccia web di amministrazione, ecc.
Mi rendo conto che il problema che ho è un compromesso tra un modello pulito e l'idea di configurazione a posto singolo e che probabilmente dovrò inquinare le Entità memorizzando tali dati di dominio non di business nelle Entità, ma io pensavo che forse qualcuno qui potrebbe avere un'idea di come affrontarlo in un modo diverso o migliore?
Grazie per la lettura.