Scrittura dell'istruzione decisionale sul livello controller

Question

Scrittura dell'istruzione decisionale sul livello controller

#1 da (3 voti)

3

Stiamo sviluppando un'applicazione REST basata su un'architettura MVC.

Il livello di servizio restituisce Optional<T> dove T potrebbe essere qualsiasi classe.

Quindi sul livello controller c'è un'istruzione condizionale che verifica se il risultato è Optional.empty , quindi restituisce una risposta personalizzata con dati [] ; altrimenti, restituire i dati effettivi in una risposta HTTP risposta personalizzata.

return ABCService
    .getById("")
    .map("custom response with actual data ")
    .orElse(Collections.empty in Custom response)
    ;

È una cattiva pratica scrivere questo codice nel livello Controller?

Stiamo restituendo Optional<T> perché non vogliamo inviare null . Se non usiamo questa condizione sul livello Controller, dobbiamo rimuovere anche Optional dal livello di servizio, che non credo sia una buona pratica.

Qualcuno può spiegare perché il codice sopra non è una buona pratica? Quali potrebbero essere le conseguenze?

api-design java rest java8 mvc

posta Mehraj Malik 17.09.2017 - 15:14

fonte

1 risposta

Leggi altre domande sui tag api-design java rest java8 mvc

Con un'API REST, esiste una convenzione per i client che convalida una richiesta senza apportare alcuna modifica? Meglio utilizzare un plist grande o molti piccoli plists durante lo sviluppo per iOS?

score 3 · Accepted Answer

Dipende davvero da come stai facendo MVC. MVC non stabilisce come comunicare M, V e C. Il tuo codice ha senso se stai facendo questo :

Manonsestaifacendo questo :

Ciòchedovrestifareingranpartedipendedacometisentiin Segregazione di responsabilità della query dei comandi .

Dicendomi che stai usando MVC non mi dice molto. È un vecchio modello di design che è stato reinventato in molti modi diversi. L'unica cosa coerente a questo punto è l'idea di separare 3 aree di responsabilità.

L'errore da un miliardo di dollari era di consentire a null di entrare nel sistema di battitura. A meno che tu non usi un linguaggio che corregge che stai vivendo con tipi nullable.

Con attenzione non restituire null è una cosa diversa. Si evita di restituire null perché il significato di null non è chiaro dal contesto al contesto e il comportamento che provoca è solitamente non intenzionale. Restituire un oggetto nullo ti consente di controllare il comportamento e chiarire il significato. Questo può essere semplice come impostare String su "" anziché null .

L'utilizzo di Optional consente di ottenere un effetto simile senza definire una classe oggetto null perché Optional è effettivamente un contenitore. Invece di sottoporvi a un null che esplode quando ti ricolleghi, Optional si comporta come un ArrayList che non contiene nulla.

Optional non si ferma null da esistente. Si limita ad abituarsi ad occuparsene. Inceppa efficacemente il if (foo != null) di controlli in Optional in modo da non doverli guardare. Funziona anche solo finché si continua a utilizzare Optional . Nel momento in cui dividi Optional e tocchi direttamente ciò che è lì, sei di nuovo indietro dove hai iniziato, a che fare con null .

Evitare fedelmente null nei tuoi ritorni può sembrare attraente ma capisci che solo perché qualcosa dice che restituisce Optional non significa che non possono ancora rovinarti e talvolta restituire un null nudo. Il sistema di battitura non può farti questa promessa. Questo è l'errore da miliardi di dollari.