Restituzione di entità JPA in Api di riposo?

Question

Restituzione di entità JPA in Api di riposo?

#1 da (1 voti)
#2 da (0 voti)

1

Recentemente ho visto così tanti sviluppatori lavorare con lo stack Spring / JPA e restituire tutte queste entità JPA sui loro restanti controller.

Secondo me è una BAD PRACTICE per diverse ragioni: Transazioni (non dovrebbe mai iniziare sui controller REST), informazioni sensibili possono essere esposte per errore, il mantenimento delle entità è difficile poiché è facile rompere l'interfaccia resto, anche molti altri.

Se hai la rappresentazione della vista come DTO, ti semplifica la vita.

Vorrei capire perché, o se davvero sono vantaggi dell'utilizzo di questo approccio.

java rest json spring jpa

posta carlos.hager 12.07.2018 - 14:52

fonte

2 risposte

Leggi altre domande sui tag java rest json spring jpa

Design: HTTP e Websockets che lavorano insieme In un software MVC, dove dovrebbe andare la logica delle funzioni che gestiscono le connessioni?

score 1 · Answer 1

Per le app piuttosto semplici, restituire tali entità funziona perfettamente e ti consente di iniziare molto rapidamente. È probabile che tu abbia bisogno di quelle per le interazioni tra database e le entità restituite di solito sono il mapping 1: 1 al database.

Per applicazioni più solide che desideri scalare meglio, aggirare completamente tali entità sulle letture utilizzando semplici query SQL e DTO è generalmente l'approccio più favorevole.

Per quanto riguarda la scrittura, a volte è anche meglio usare una qualche forma di comando nel livello dell'applicazione (controller), come RegisterUser DTO, e convertire il comando solo nella reale entità JPA nel tuo livello di servizio.

score 0 · Answer 2

Ho lavorato in grandi applicazioni web usando lo stack JavaEE e questo era perfettamente accettabile. Potresti usare queste entità nel livello JSP, nel livello Beans, anche per altre cose come le convalide ecc. Ciò ti ha reso la vita più facile e ha mantenuto il codice semplice e pulito. La soluzione generale è ancora conforme all'architettura JavaEE.

Tuttavia, quando si utilizza un approccio simile ma al di fuori di JavaEE, si possono generare problemi che altrimenti non si verificherebbero. Il comportamento di queste classi di entità al di fuori del contenitore JavaEE, l'esempio in Spring o qualsiasi altro framework, ad esempio, non sarebbe definito. Ho sempre trovato che usare in modo semplice POJO o DTO o JSON in questi casi è molto più vantaggioso.