Mapping di tutte le proprietà degli oggetti business vs Mappatura delle proprietà necessarie degli oggetti di business

Question

Mapping di tutte le proprietà degli oggetti business vs Mappatura delle proprietà necessarie degli oggetti di business

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

2

Sto ricevendo oggetti in JSON e attualmente l'app utilizza solo una piccola quantità delle proprietà che ricevo. Mi chiedo quale dei seguenti è la migliore pratica, o semplicemente generalmente consigliato.

Sarebbe meglio che il server inviasse effettivamente oggetti parziali (dati più piccoli)? In questo modo, non dovrei preoccuparmi di mappare di più o meno.
Dovrei mappare l'oggetto completo nel mio modello, sapendo che non avrò bisogno di tutte quelle proprietà, ma almeno corrisponderanno al server?

In questo momento, ho deciso di non farlo, dato che potrebbe esserci sempre un cambiamento, e non mi piace avere un codice "inutile", dal momento che ritengo che questo non sia nella categoria "rendilo a prova di futuro".

model

posta Gil Sand 15.03.2016 - 11:35

fonte

3 risposte

Leggi altre domande sui tag model

Utilizzo dell'output del software GNU GPL in scopi commerciali [duplicato] L'SRP alimenta l'accoppiamento stretto?

score 5 · Answer 1

Basta mappare e inviare ciò di cui hai bisogno. Ciò mantiene il codice leggibile e riduce il traffico di rete. Tuttavia, crea le strutture del codice in modo che siano facilmente estensibili quando devono essere modificate.

Alcuni principi applicabili:

Quando esiste la possibilità che tu voglia estendere la tua API, dovresti prendere in considerazione il controllo delle versioni dall'inizio in modo che l'API REST sia facilmente estendibile senza compromettere la funzionalità per i client esistenti.

score 5 · Answer 2

Se hai esattamente un'app e il server invia il JSON solo a questa app, dovresti seguire il consiglio di @ simon. Tuttavia, quando hai una dozzina di app, ognuna di esse ha bisogno di una parte diversa dei dati, quindi personalizzare il JSON per ognuno di essi (quindi fare dodici diverse API, una per ogni app) potrebbe diventare ingombrante, inefficiente e errorprone. In tal caso, dovrai fare un compromesso tra l'ottimizzazione della rete e la manutenzione dell'API.

Per quest'ultimo caso, due o tre diverse "viste" riutilizzabili per il tuo oggetto aziendale potrebbero essere un compromesso pratico. Inoltre, se si utilizza un generatore per creare il JSON e il modello nella propria app da meta modello o schema di dati, lasciare che generi alcuni attributi aggiuntivi di cui non si ha bisogno immediatamente non è una violazione di YAGNI. Per un generatore non fa una grande differenza se genera 10 attributi o 20 - potrebbe essere più difficile rendere il generatore così flessibile da generare API diverse, e quindi è discutibile se è più flessibile di quanto realmente necessario.

EDIT: Esiste un altro approccio possibile: ogni app potrebbe indicare al server in qualche tipo di query esattamente quali attributi ha bisogno e il server lo consegna in maniera generica. Una rapida ricerca su google rivela che esistono già lingue di query JSON disponibili per questo scenario, vedi ad esempio questo ex post SO o JSONiq .

score 0 · Answer 3

Questo è un problema "dal basso verso l'alto" o "dall'alto verso il basso".

Nella maggior parte dei casi, adotterei l'approccio "dal basso verso l'alto" e mapperò proprio quello di cui ho bisogno mentre vado, specialmente se non è chiaro dove andrà l'applicazione. Quindi vuoi mantenere le cose aperte.

L'approccio "top down" funziona meglio quando il numero di casi d'uso è limitato e il sistema è sostanzialmente "chiuso". Quindi l'argomento è "Se faccio tutto ciò di cui ho bisogno per questa volta, non avrò più bisogno di fare altro". Un piccolo sforzo in più farà risparmiare molto dolore in futuro. Ciò si verifica quando è improbabile che nuovi "percorsi" ti portino fuori da ciò che hai fatto, se l'hai fatto "tutto" la prima volta.