Abbiamo un software con lo scopo di aiutare gli utenti a creare le proprie applicazioni. Deve essere molto allentato con l'infrastruttura: ad esempio, posso immaginare che gli utenti lo eseguano sul database MySQL anche su MongoDB.
Abbiamo moduli di funzionalità. In ogni modulo abbiamo quello che chiamo pure modelli - contenente solo ciò che è richiesto. Ad esempio, un Book contiene autori, titolo, numero di pagine e così via.
Il problema è che abbiamo bisogno di raggruppare metadati aggiuntivi con i modelli che dipendono dall'altra infrastruttura! L'esempio banale è un codice tecnico di Book : per i repository MySql questa è la chiave primaria della tabella, anche altri id; per repository MondoDB è solo la sua chiave di stringa. Come vedi, le informazioni sui metadati non sono uniche e dipendono dall'infrastruttura.
Questi dati aggiuntivi sono forniti dall'implementazione concreta del repository, ogni volta che il modello viene memorizzato o recuperato dal repository.
Ora il problema: vorremmo "nascondere" questo dall'interfaccia Book (cioè modello) - poiché non ha senso raggruppare tutte le varianti dei metadati in Book .
Come risolvere questo?
[A] Possiamo avere fabbriche che costruiscono i nostri modelli, a seconda del repository usato. Quindi per il repository SQL, abbiamo un factory SQL, che costruisce una variante SQL del modello. Non sono sicuro che mi piaccia.
[B] Semplicemente aggiungiamo una proprietà a Book per ulteriori metadati, come repoMetaData . Questa proprietà è strettamente tecnica, cioè non è legata al business. Quindi qualsiasi implementazione di repository può iniettare qualsiasi cosa all'interno. Book diventerebbe RepositoryAware (un'interfaccia).
Mi piace di più il [B], ma a qualcuno non piace il fatto che stiamo aggiungendo elementi tecnici all'interfaccia del libro. In che misura ha senso aggiungere ulteriori informazioni tecniche ai modelli?