REST non è appropriato per le applicazioni aziendali a causa della necessità di distribuire la logica di business sui livelli. È richiesta un'alternativa REST!

2

Ho un'applicazione Spring + Java Server Faces (Facelets) per la quale vorrei creare la versione Single Page Application (SPA), ad es. usando AngularJS (che è il framework GUI migliore e più popolare). Ma dopo alcune indagini sulle tecnologie, sono giunto alla conclusione che REST (che è una necessità per AngularJS) è una cattiva scelta per applicazioni aziendali complesse, perché è necessario dividere la logica di business tra i livelli software.

Lascia che ti spieghi questo. Nell'applicazione Spring + JSF tutta la logica di business è stata codificata in layer speciali: entità e servizi Spring. In Spring + REST + AngluarJS questo dovrebbe essere diverso. Non voglio riscrivere (spostare) la logica di business da Spring / Java a AngularJS / JavasScript, ma ovviamente sono obbligato a farlo. Ci sono un problema e 3 tipi di logica aziendale nella mia applicazione che richiedono considerazione.

  • Numero uno. Spring ha fornito un'interazione statica con l'oggetto business. E.g. si potrebbe aprire una nuova fattura, aggiungere clienti, aggiungere linee di fatturazione, ricalcolare sconti, imposte sulle vendite, totali, aggiungere informazioni sulla spedizione e così via. Sessione e oggetti business sono stati archiviati nella sessione lato server di Spring. L'architettura REST richiede che gli oggetti business di sessione abd siano negozi nel client (oggetti JavaScript Browser). Quindi, la migrazione richiedeva la riscrittura quasi completa di queste applicazioni.
  • Tipo di logica aziendale 1. Validatione. È stato possibile includere regole di convalida negli oggetti lato server di Spring. REST richiede che la convalida venga eseguita in oggetti JavaScript, poiché è impossibile ad ogni modifica di ciascun campo inviare lo stato client completo al server per la convalida.
  • Tipo di logica aziendale 2. Modifica monitoraggio e propagazione. E.g. se l'utente aggiunge la riga di fattura con l'articolo alla fattura all'interno del modulo di domanda, allora il programma può recuperare tutti gli sconti rilevanti per questo cliente, questo articolo e questo momento. Gli sconti possono essere applicati alla linea della fattura e le modifiche possono essere propagate per aggiornare l'imposta sulle vendite e i totali della fattura. È quasi impossibile eseguire questo tipo di propagazione delle modifiche in REST, se parte dell'oggetto business in sessione è archiviata sul lato server.
  • Tipo di logica aziendale 3. Elaborazione di oggetti business. E.g. se la fattura è contrassegnata come ordinata, l'applicazione Spring può apportare modifiche estese ad altri oggetti del database, ad es. aggiornare i livelli di inventario, pianificare le attività di spedizione, creare entrate di contabilità e così via. Spring potrebbe farlo e Spring sarà ancora in grado di farlo nell'applicazione REST. Questo è l'unico tipo di logica aziendale che posso riprendere dalla mia domanda iniziale.

Quindi - mi sembra che la migrazione da Spring + JSF a Spring + AngluarJS richieda la riscrittura di quasi tre quarti (3/4) di applicazione. L'aggiunta di un nuovo tipo di GUI (e di un nuovo tipo di comunicazione - REST) a un'applicazione esistente dovrebbe essere così coinvolta?

Sto pensando a due problemi

  • Alternativa a REST. Tutti i miei problemi di migrazione derivano dal requisito che AngularJS deve utilizzare REST per la comunicazione con gli oggetti e la sessione dello stato del server (Spring). Forse ci sono alternative a REST? JSF / facelets sta già facendo molto JavaScript per la comunicazione con il server, forse AngluarJS può essere adattato a questo?
  • Sono a disagio nella scrittura della logica di business in JavaScript . Stiamo facendo molto lavoro per la generazione automatica del codice Java dai modelli e vorremmo mantenere questa esperienza. Ci sono molti strani strani su OO JavaScript. E accanto a Java è ricercato molto di più in questo senso.

Quindi - la domanda principale è - esiste un'alternativa alla comunicazione REST per applicazioni aziendali SPA (AngularJS) con la logica di business stateful implementata nell'applicazione lato server (Spring / Java / Enterprise Java)?

    
posta TomR 21.05.2016 - 13:19
fonte

1 risposta

6

C'è un equivoco grossolano da qualche parte. Penso che sia vicino a questa idea.

In Spring+JSF application all the business logic was encoded in special layer - Spring entities and services. In Spring+REST+AngluarJS this should be different. I don't want to rewrite (move) business logic from Spring/Java to AngularJS/JavasScript but obviously I am required to

No, non è affatto ovvio. Perché i dettagli di implementazione del tuo stato di applicazione richiedono di riscrivere il tuo modello di dominio ? Sono preoccupazioni completamente ortogonali.

REST architecture requires that session and business objects are stored in client (Browser JavaScript objects).

Assolutamente no. L'architettura REST richiede l'invio di rappresentazioni dello stato dell'applicazione al client.

In parole semplici, il client e il server inviano solo i messaggi avanti e indietro, in modo che il client possa navigare con successo nel protocollo dell'applicazione. Gli effetti collaterali che il protocollo dell'applicazione ha sul modello di dominio sono limitati al server.

Rivedi di Jim Webber"> Come ottenere una tazza di caffè .

    
risposta data 21.05.2016 - 14:26
fonte

Leggi altre domande sui tag