Attualmente sto lavorando a un progetto che richiede una struttura del modello complicata e sto lottando con la scelta dell'architettura giusta.
Prima di tutto, ci sono diversi modelli interdipendenti. Le modifiche in un modello possono innescare cambiamenti in molti altri modelli. Ad esempio, l'utente inserisce una query, il primo modello controlla il database per il tipo di query e il secondo modello richiede i suoi dati a seconda del tipo di query.
In secondo luogo, ogni modello può avere diverse origini dati. Le origini dati vengono utilizzate in modo condizionale, in base alla configurazione del sistema.
L'app deve funzionare senza problemi, ad esempio, se un'origine dati non restituisce le informazioni richieste, il modello deve provare a utilizzarne un'altra.
Una cosa importante è che il codebase verrà espanso con altri modelli. Quindi i modelli, le origini dati ecc. Devono essere molto modulari.
Attualmente esistono diversi modi in cui posso organizzare il livello del modello:
-
Modelli "stupidi" ricreati dagli oggetti di fabbrica quando i dati di input (o un modello correlato) cambiano. Le dipendenze del modello vengono risolte in un oggetto operazione, incapsulando l'intera routine di aggiornamento. L'oggetto operazione è configurato ed eseguito da un modello di dominio. Però non so dove iniettare un'origine dati.
-
Modelli "intelligenti" con logica di aggiornamento incapsulata in essi. Ogni modello richiede una sorta di mapper / data-source-manager, che funziona come proxy per diverse origini dati. I modelli segnalano i loro aggiornamenti a un modello di dominio. Le dipendenze sono risolte da un oggetto model controller o dependency manager.
Quale architettura è più appropriata qui?
Mi sto appoggiando al primo perché è (secondo me) meglio lavorare con modelli immutabili, aggiornando l'intero albero sul cambio di input. Questo approccio offre diversi vantaggi: ad esempio, è più facile serializzare come la presenza del modello è uguale a uno stato finito. Ma sono davvero incerto sulle origini dati ...