Sto cercando di sviluppare applicazioni aziendali con backend separato (persistenza, logica aziendale, flussi di lavoro lato server) e frontend (presentazione, alcune logiche di business) che comunicano tra loro utilizzando l'API / JSON REST. Questa architettura è riconosciuta come buona in È normale che il design disgiungi completamente le applicazioni Web di backend e frontend e consente loro di comunicare con l'API REST (JSON)?
Nel mio caso ho scelto Java / Hibernate / Spring per backend e Angular2 / 4 per forntend, ma la mia domanda è rilevante per qualsiasi altra combinazione di tecnologie, ad es. con il backend di Laravel e il frontend Bootstarp, con il backend di .NET EntityFramework e con qualche altro frontend correlato a JS SPA.
Mentre procedo con la mia domanda, sono bloccato da un grosso problema: il mio backend recupera in modo evidente il grafico delle entità composto dalle entità Invoice / InvoiceLine / Good. Posso convertire questo grafico in JSON usando le librerie standart (ad esempio Jackson in Java) e posso inviarli al frontend. Frontend esegue l'elaborazione di tali entità JS e le invia al back-end. Everyting va bene finora. Il riattacco delle entità ricevute al contesto di persistenza è il problema centrale della mia domanda: come dovrei farlo, è possibile fare il riattacco intelligente del grafico completo delle entità e perché non esiste un supporto diffuso per questo scenario librerie (Hibernate e così via)? I problemi principali sono il riattacco del grafico delle entità. È possibile ricollegare una entità senza problemi, ogni libro sulle tecnologie pertinenti fornisce esempi. Il problema è che il grafico completo delle entità può essere enorme. E il riattacco dovrebbe rilevare qualsiasi possibile sequenza di modifiche di questo grafico di entità. Per esempio. alcuni InvoiceLines possono essere aggiunti, alcuni cancellati, altri aggiornati, alcuni possono avere prezzi modificati, altri possono riferirsi a beni completamente nuovi e così via, così via.
Finora conosco solo una tecnologia che può imitare in modo completamente chiaro e rigoroso tale "riattacco" ed è Delphi ClientDataSet con funzionalità CachedUpdates (credo che la vecchia scuola Microsoft avesse anche DataSet Componend): questa funzione registra ogni modifica che è fatto sul grafico dei ClientDataSet connessi e applicando CachedUpdates al database, tutti gli aggiornamenti registrati (siano essi inserti, aggiornamenti o eliminazioni) vengono applicati uno alla volta al database.
Quindi - le attuali tecnologie di riaccostamento (per Hibernate, per EntityFramework, per Yii ActiveRecord, per PHP Doctrine / Propel, ecc. ecc.) non hanno questa nozione sugli aggiornamenti in cache, sulla sequenza di modifiche, quindi - tecnologie di riaccostamento attuali confrontare solo il prodotto finale con lo stato attuale del database e in qualche modo dedurre o non dedurre una sequenza davvero complessa di istruzioni SQL. La mia esperienza è che le tecnologie di riattacco semplicemente non possono farlo e non c'è modo di controllare questo processo, non vanno oltre il lavoro con singole entità o liste di entità.
Quindi - come dovrei risolvere il problema del riaccoglimento nell'applicazione web che viene fatto da applicazioni backend e frontend che comunicano con REST API / JSON e invia tra i suoi grafici di entità complessa e in continua evoluzione?