Introdurre oggetti di trasferimento dati o esporre il modello di dati complessi in REST

Question

Introdurre oggetti di trasferimento dati o esporre il modello di dati complessi in REST

#1 da (4 voti)

6

Stiamo lavorando su un'applicazione MVVM. Jersey (backend) che espone un'interfaccia REST e AngularJS (frontend) è l'unico consumatore di questa interfaccia. L'applicazione utilizza un modello di database complesso (modello dati), diverso dal modello presentato all'utente nel browser (modello di visualizzazione).

Attualmente abbiamo riscontrato il seguente dilemma:

per introdurre classi DTO (Data Transfer Object) che conterranno tutti gli attributi richiesti per richiamare operazioni di business logic complesse sul nostro modello
esporre il modello di dati complessi esistente senza introdurre le classi DTO

L'approccio 1 consentirà semplicemente ai client dell'interfaccia REST, in quanto non dovranno comprendere il modello di dati e dovranno solo fornire i valori di tutti gli attributi richiesti nelle classi DTO. Tuttavia, questo approccio richiede l'introduzione di un layer di mappatura nel back-end, da / verso il modello dati da / verso il modello di visualizzazione.

L'approccio 2 produce meno codice nel back-end, ma probabilmente renderà il codice nel frontend più complesso in quanto dovrà fare la mappatura dell'input dell'utente al modello di dati esistente.

Dal punto di vista del progetto REST 2 sembra essere meglio, ma esponendo il modello dei dati in REST sempre la soluzione migliore?

language-agnostic design architecture rest

posta Adam Siemion 07.12.2014 - 13:52

fonte

1 risposta

Leggi altre domande sui tag language-agnostic design architecture rest

Numero di stringhe contenenti una sottostringa specifica Quando si applica la segregazione dell'interfaccia, si dovrebbero separare le interfacce per i setter regolari e le operazioni matematiche?

score 4 · Accepted Answer

expose the existing complex data model without introducing DTO classes

Uno dei principali difetti di questo approccio è quello dell'accoppiamento del livello di accesso ai dati con l'API. Può andare molto male molto rapidamente se questi modelli sono usati altrove eccetto API. Al momento lavoro su un progetto in cui sia l'interfaccia web che l'API JSON (tipo REST, ma non del tutto) utilizzano le stesse entità di Hibernate: è fragile , poiché ogni cambiamento in un punto influenza l'altro. La riusabilità non funziona in questo modo, credo.

A volte è sufficiente disporre di DTO quando i modelli non si adattano all'API. Ad esempio, se hai alcune regole di convalida difficili o alcuni dati che desideri nascondere dai client API. Puoi diventare pazzo con le annotazioni, eppure non funzionerà sempre.

Lavoro anche su altri progetti che hanno sia l'API JSON che l'interfaccia web, ma l'API usa il proprio livello di accesso ai dati ( jOOQ ). Funziona bene, nonostante ci siano due modi per accedere ai dati. È più semplice scrivere query personalizzate per l'API e inserire i dati in DTO per iniziare piuttosto che avere un certo livello di "trasformatori" dalle entità dati alle DTO. Funziona anche molto più velocemente di qualsiasi ORM ed elimina l'intera classe di problemi relativi a scaricamento pigro e pattern "Apri sessione / EntityManager in visualizzazione".

Pertanto, raccomando l'uso di DTO e considerando anche l'utilizzo di un livello di accesso ai dati separato non-ORM per l'API. ORM è adatto per interfacce Web (e probabilmente API in stile RPC), ma sembra causare molti problemi con REST - è correlato all'idea di CQRS .