Modello di oggetto Rich nel contesto di una buona API REST e di un modello di oggetto Rich esistente sul lato server

Quando si tratta di gestire i framework di un client web, l'approccio migliore è mantenere gli oggetti semplici, perché

1. Complessità API - > Meno complessi metodi API

2. Concurrency - > Se viene caricato un oggetto complesso e il suo tempo di vita è apparentemente più lungo e quando è necessario persistere, potrebbe essere più probabile che possa essere stato modificato da qualche altro utente / processo. Quale potrebbe causare errori. Mantenendo il tempo di vita dell'oggetto più basso, questo può essere evitato.

3. Convalide - > quando hai un modello di oggetti ricco ci sono più e più complesse convalide di cui hai bisogno. Se lo stesso modello si estende su più viste (è probabile che lo sia), quindi mostra i messaggi quando la persistenza dell'oggetto è un'attività complessa.

4. Rendimento - > Anche se si tratta di una modifica minore, se viene utilizzato un modello ricco, è necessario recuperare l'intero modello, causando l'accesso a più tabelle e recuperando una grande quantità di dati.

Puoi avere un'app snella e leggera e avere ancora un modello di oggetti ricco.

Se stai utilizzando Angular, significa che probabilmente stai scrivendo un'applicazione a pagina singola e stai guidando l'interfaccia utente dai servizi web. Questi servizi Web dovrebbero fornire i dati necessari per l'interfaccia utente. Sul server, puoi avere un modello di dati e un livello di applicazione complessi come richiede il dominio.

Gli oggetti ViewModel sono il livello di astrazione che ti consente di avere il tuo modello di oggetto complesso, mantenendo l'interfaccia utente snella come hai bisogno.

Ho fatto entrambi questi approcci in passato e tendo verso i POJO semplificati. Il motivo principale è che consente e impone che la logica aziendale venga effettivamente eseguita sul server.

Quando eravamo soliti inviare il modello completo completo al client, il nostro codice cliente iniziava ad accumulare ovunque piccoli pezzi di logica aziendale e diventava piuttosto cattivo. E questo ha reso il riutilizzo del codice completamente impossibile in quanto era legato a un particolare schermo.

Quindi preferisco semplicemente effettuare il preprocesso dei dati esattamente per le necessità del client e lasciare che si occupi solo dello schermo.

L'altro motivo per cui ho visto che i POJO piccoli funzionano meglio è la velocità. (Che non è vero in tutti i casi). Ma supponendo che l'utente voglia solo modificare questa piccola parte. Con il modello ricco tendi a dover trascinare l'intera cosa al client, modificando leggermente il bit e salvando il tutto. A seconda delle dimensioni del modello e del tipo di interazione dell'utente, questo potrebbe o meno essere un problema.

E l'ultima è l'interattività e la concorrenza. (Che a seconda dell'applicazione potrebbe essere o non essere necessario.) Ma i POJO e i servizi personalizzati consentono di salvare le modifiche mentre l'utente va, in piccoli pezzi e si aggiorna spesso dal database. Che a sua volta riduce i possibili problemi di concorrenza, che arrivano quando due utenti modificano la stessa grande quantità di dati e poi salvano.

D'altro canto, se si ha a che fare con un modulo di grandi dimensioni con più sottoschermate che viene compilato una sola volta, potrebbe essere meglio inviare l'intero modello al client, elaborarlo lì e salvarlo nuovamente. Questo ha il problema di avere la logica di business sul client. Il modo in cui abbiamo lavorato in passato è codificare la logica di business nel modello (come l'invio di regole di convalida come parte del modello).

Invio di dati via cavo a un'API È, penso, uno dei driver principali di un approccio in stile ADM / POCO alla programmazione (vedi la mia domanda: link dove tocco alcuni degli stessi punti)

Se segui la rotta OOP, devi affrontare i problemi di serializzazione di un modello che custodisce gelosamente i suoi dati e quindi crea un modello simile sul lato server da quei dati che potrebbero richiedere forse le stesse funzioni di base, ma tutti le guide alle best practice (per una buona ragione) mettono in guardia dall'usare lo stesso modello su entrambi i lati del servizio.

La rotta ADM rende tutto più semplice, ma qui c'è il pericolo che la funzionalità del servizio diventi complessa, il tuo semplice approccio procedurale risulterà in un codice "cattivo", inoltre, c'è una tentazione per questo stile sparsi sul lato dell'applicazione dell'interfaccia.

Tuttavia, penso che tu possa avere il meglio di due mondi qui. Con il servizio non puoi aggirare il fatto che stai programmando una funzione che prende come parametro una struttura di dati e facendo coincidere il tuo programma questo fatto è la cosa migliore da fare.

Come puoi vedere nel mio esempio, tuttavia, non c'è motivo per non rendere il servizio stesso conforme a OOP all'interno del vincolo di "devi ricevere e restituire una struct"

Dal lato app la restrizione di "alcuni metodi non sono eseguiti su questa macchina" è più difficile da gestire. È possibile iniettare il servizio nel modello e quindi fare in modo che model.method () chiami il servizio, ma a mio parere ciò porterà a un codice molto forzato.

Oppure puoi utilizzare l'approccio ADM per chiamare i metodi sugli oggetti serviceclient che passano nei tuoi modelli struct like. Ancora una volta questo approccio non OOP corrisponde alla realtà della situazione, pur consentendo di mantenere il resto del codice sensibile