Gestione delle maschere di campo sul client tipizzato staticamente

Question

Gestione delle maschere di campo sul client tipizzato staticamente

#1 da (1 voti)

3

Diciamo che ho un'API REST, che ha la capacità di fornire una maschera di campo (ad esempio, l'API può restituire M di attributi N dove M è un sottoinsieme di N).

Se un client tipizzato staticamente (esempio: uno scritto in Java) richiede i dati da questa API, esiste un modo per gestire "con garbo" i problemi di nullability.

Se vengono richiesti campi N, vengono richiesti M, quindi i campi [N-M] sono "null" ...

Se la classe di serializzazione ha tutti i campi M; allora N-M sarà nullo. Se questa classe viene passata ad un'altra logica, il codice verrà sottoposto a controlli "nulli" per evitare NPE. (I tipi Optional arg limitano solo in minima parte il problema).
L'altra opzione consiste nel creare diversi "oggetti di trasferimento dati (DTO)" per gestire varie maschere di campo "comuni" e garantire che tutti gli attributi di questi DTO non siano nulli, quindi il codice chiamante non devono fare controlli nulli prima dell'accesso di ogni attributo (esempio: ho 3 DTO: SuperSimple, Simple, Detailed con maschere di campo preselezionate). Però; questo può portare all'inquinamento da DTO nel codice (potenzialmente potresti avere 2 ^ N di tali DTO che sono un trascinamento sulla manutenibilità)

Apprezzerei i tuoi pensieri in forma di a) schemi di progettazione b) caratteristiche dei framework o c) librerie indipendenti che hanno come target questo problema

Grazie

design-patterns rest static-typing web-framework

posta labheshr 05.12.2018 - 03:28

fonte

1 risposta

Leggi altre domande sui tag design-patterns rest static-typing web-framework

Come definire le direttive del modello (dal punto di vista dell'API)? Portare un progetto legacy ampio e complesso sotto controllo git

score 1 · Answer 1

Dipende veramente dai tuoi requisiti di business logic dalla risposta dell'API REST.

Per quanto riguarda le soluzioni proposte:

Ti suggerisco di avere questo codice di controllo al di fuori della funzione logica effettiva, e di avere la funzione logica specifica un contratto / lambda che specifichi quali campi sono richiesti per questa funzione per passarlo a lei . Se puoi, cerca una rappresentazione uniforme che il contratto possa verificare rapidamente.
Le DTO saranno difficili da mantenere come hai notato. Per quanto riguarda l'esplosione esponenziale, la soluzione 1 può deteriorarsi anche a un numero esponenziale di contratti (anche sui controlli Null correnti) ma non vedo come evitarlo sulle informazioni correnti che mi vengono fornite. (Nel peggiore dei casi se hai una logica su misura per ogni sottoinsieme specifico di N)

Dipende da più informazioni per cercare di evitare questo caso-esplosione, per esempio se hai una logica che richiede un determinato campo solo puoi avere un iteratore che si sposta sull'oggetto risposta REST (passando sopra campi null) e invoca dinamicamente l'operatore corretto per-ciascuno.