Serializzazione dei dati per elaborare la logica aziendale

Molto dipende dalle tue intenzioni. La serializzazione dei dati in questo modo solo per passare alla logica di business di una singola applicazione, sembra uno spreco, quando si dovrebbe passare un oggetto nativo dall'ORM all'oggetto che incapsula BL che modificherà lo stato e restituirà l'oggetto all'ORM per la persistenza .

D'altro canto, se si dispone di più applicazioni distribuite che gestiscono diversi aspetti del dominio, quindi avvolgere il DB in un'API per fornire dati serializzati (JSON o XML) è una buona idea.

Per esempio: devo occuparmi di un database legacy fornito dal fornitore piuttosto folle in cui un grosso ostacolo è l'incapacità di modificare lo schema del DB oltre all'aggiunta della vista occasionale. Ho questo DB (così come un paio dei nostri altri data store "enterprise") racchiusi in un'API REST. La maggior parte delle nostre applicazioni rivolte agli utenti, così come i demoni che monitorano il DB per determinati eventi, comunicano con l'API. In questo modo posso avere il seguente flusso di lavoro:

1. Le classi OR / M racchiudono ciascuna una singola tabella nel DB. Un oggetto == un record.
2. Le classi Decorator gestiscono la presentazione, inclusa la composizione di oggetti più complessi da semplici oggetti del modello.
3. Le classi controller rispondono alle richieste con una rappresentazione JSON dell'oggetto appropriato per l'applicazione client.
4. Clent elabora i dati, POST o PUT dell'oggetto JSON di nuovo all'API
5. Richieste controller per salvare l'oggetto, che viene decomposto di nuovo agli oggetti del modello e mantenuto dall'O / RM.

Ciò aggiunge una notevole complessità.

Se devi gestire archivi di dati eterogenei, applicazioni distribuite, ecc., questa è una soluzione eccellente. Ma se non hai questi requisiti, la regola generale è Non ne hai bisogno.

I database forniscono già un formato standard per le loro risposte e i driver del database sanno già come interpretarli / usarli. I passaggi di marshalling e antagonismo di JSON sono quindi superflui se il risultato nel suo formato non verrà trasferito su un altro sistema.

Secondo me dovresti spostarti di più verso l'incapsulamento, con oggetti e strutture nativi invece di passare un frammento di dati serializzato intorno.

L'unico vantaggio che vedo è il processo di test; è possibile iniettare metodi con dati JSON casuali e non è necessario un database. Ma è una specie di grande compromesso per così tante perdite di perfomance.

Di solito, lavoro in lingue / ambiente che sono più vicini ai sistemi rispetto all'esempio qui, quindi la mia risposta potrebbe essere leggermente distorta. Tuttavia, c'è un concetto / modello interessante che ho trovato con molti buoni designer.

Di solito, al fine di promuovere il codice da riutilizzare, alcune cose devono essere generalizzate. Esempi classici di generalizzazione sono libri di testo esempi di ereditarietà; e ci si rende conto che una volta un'API generica per una classe di oggetti aiuta ad evolvere i sistemi. Sappiamo tutti che è bene astrarre le funzionalità comuni rispetto a quelle specifiche in questo modo.

Tuttavia, ho visto questo con molti designer che a volte provano a fare super generalizzazione . Uno degli esempi che ho visto è una classica applicazione C ++. Invece di generalizzare mantenendo i parametri più comuni specifici di una funzione astratta (virtuale), il codice esegue super generalizzazione passando i parametri come lista arbitraria di coppie nome-valore . Ora qualsiasi funzione / metodo può essere banalmente generalizzata se tutti gli argomenti / parametri rilevanti sono serializzati e passati alla funzione e de-serializzati durante l'elaborazione.

Ma una tale super generalizzazione è pessima. Non solo aggiunge un sovraccarico all'aggiunta del processo di serializzazione / deserializzazione, ma soprattutto la semantica è persa . Ora la funzione del callee può inserire parametri arbitrari e l'intera cosa inizia a essere utilizzata in modo improprio al di là del contesto. Ti imbatti anche in parametri non gestiti, errori di ortografia, parametri fuori contesto e così via; tutto questo perché non c'è modo di controllare quale tipo di parametri può entrare.

Come regola generale, sarei sempre preoccupato di super generalizzazioni ed essere piuttosto semplice .

NOTA: il modello che hai descritto sopra NON è ORM. In ORM, in genere tratti un record DB con un Oggetto equivalente che ha lo stesso attributo. La rappresentazione basata su JSON richiede ancora la traduzione in oggetto nativo prima dell'uso.