Penso che questo sia un problema di progettazione comune, ma continuo a grattarmi la testa ogni volta che lo affronto.
Da un lato, abbiamo la nostra API che invia o riceve strutture semplici che possono essere utilizzate da app Web, dispositivi mobili, ecc. Potremmo potenzialmente disporre di più API destinate a dispositivi diversi. Dall'altra parte abbiamo il nostro modello di dominio interno che può o meno corrispondere alle entità dell'archivio dati.
Considera di assumere i seguenti POJO per aiutare la discussione.
@POST
public addBlogPost(BlogPostApi blogPost) { ... }
// api model
public class BlogPostApi {
...
}
// domain model
public class BlogPost {
...
}
// db model
public class BlogPostEntity {
...
}
In primo luogo, potremmo usare lo stesso modello in tutti e tre i livelli. Mentre quella potrebbe essere una soluzione per servizi molto semplici, di solito non è una buona idea poiché tutti gli strati sono accoppiati implicitamente. Quindi, assumerò che vogliamo usare un oggetto modello diverso per 'strato'.
Un approccio che ho visto ampiamente utilizzato è la creazione di adattatori tra livelli. Mentre questo risolve il problema, crea un'esplosione di classi che è necessario mantenere. Nel caso (comune) quando si aggiunge un nuovo campo all'archivio dati che deve essere esposto sull'interfaccia utente, è necessario modificare 3 POJO + 2 adattatori. C'è sempre il rischio di dimenticare di cambiare uno di quelli. Questo processo potrebbe essere leggermente automatizzato, con l'uso di una libreria di mappatura di oggetti.
Un altro approccio che ho sentito è l'uso delle interfacce. Due o più classi implementano la stessa interfaccia che espone i metodi get / set per i campi "comuni". Ciò elimina il rischio di dimenticare di cambiare qualcosa, ma crea un accoppiamento. Inoltre, trovo questo uso delle interfacce errato, dal momento che le interfacce dovrebbero esporre funzionalità.
Sono inclinato verso i mappatori di oggetti. Qualcuno sa di una oluzione per questo problema?