Ho un sistema in cui i dati sono memorizzati in un archivio persistente e letti da un'applicazione server. Alcuni di questi dati vengono sempre visualizzati dal server, ma alcuni vengono passati inalterati ai client.
Quindi, c'è una grande tentazione di persistere i dati - se intere righe / documenti o singoli campi / sotto-documenti - nella forma esatta che il client può usare (ad esempio JSON), in quanto ciò rimuove vari strati di boilerplate, sia sotto forma di SQL procedurale, un ORM, o qualsiasi struttura proxy che esiste solo per contenere i valori prima di dover ricodificarli in un modulo adatto al cliente. Questo modulo di solito può essere utilizzato anche sul server, anche se la logica di business potrebbe dover vivere al di fuori dell'oggetto,
D'altra parte, questo approccio finisce col perdere dettagli di implementazione ovunque. 9 volte su 10 sono contento di leggere una struttura JSON dal DB e inviarla al client, ma 1 ogni 10 volte devo conoscere i dettagli di quella struttura implicita (ed essere in grado di refactoring per accedere a se i dati memorizzati cambiano mai). E questo mi fa pensare che forse dovrei inserire questi dati in oggetti di business separati, in modo che la logica aziendale non debba cambiare quando lo schema dei dati funziona. (Anche se potresti argomentare, questo sposta il problema anziché risolverlo.)
C'è un fattore complicante nel fatto che il nostro schema di dati cambia costantemente rapidamente, al punto in cui abbiamo abbandonato il nostro precedente sistema ORM / RDBMS in favore di MongoDB e uno schema implicito che era molto più facile da utilizzare. Finora non ho deciso se le modifiche rapide dello schema mi fanno desiderare oggetti business separati (quindi i calcoli sul lato server richiedono meno refactoring, poiché tutte le modifiche sono limitate al livello di persistenza) o per nessun oggetto di business separato (perché ogni cambiamento allo schema richiede che gli oggetti business cambino per rimanere sincronizzati, anche se il nuovo sottooggetto o campo non è mai usato sul server eccetto per passare verbatim a un client).
Quindi la mia domanda è se sia sensato archiviare oggetti nel formato che di solito saranno usati, o se è meglio copiarli in oggetti di business intermedi per isolare entrambi i lati l'uno dall'altro (anche quando non è così strettamente necessario)? E mi piacerebbe sentire da chiunque altro abbia avuto esperienza di una situazione simile, forse scegliendo di mantenere XML o JSON invece di avere uno schema esplicito che deve essere assemblato ogni volta in un formato client.