Firma del metodo preferito per il metodo API che coinvolge le interazioni DB

0

Recentemente sono entrato in discussione su come dovrebbe apparire la firma del metodo per un metodo API che non espone gli oggetti interni utilizzati dall'applicazione al chiamante. Ecco come appare la situazione:

  1. La nostra API dovrebbe esporre un metodo per dire,

    public int updateSummary(String summaryMessage) {
    
          update_in_DB(summaryMessage);
          if (success) return 1;
          return -1;    }
    

o

    public void updateSummary(String summaryMessage) {

          update_in_DB(summaryMessage);
         }

Questo metodo può essere richiamato dai client per aggiornare il riepilogo delle operazioni.

  1. Il dibattito era, cosa dovrebbe essere Return_Type?

    i. vuoto o,

    II. qualcosa come int o enum che trasmette informazioni sul fatto che l'operazione abbia avuto successo o meno.

    III. Return_Type non può essere di tipo object / entity che rappresenta l'oggetto reale perché esporrà internals dell'applicazione al chiamante.

il mio punto è, aggiungendo un tipo di ritorno come int / enum renderà il metodo testabile (tramite unit test) anche, esso consente al chiamante di agire se questa operazione fallisce. Ma a parte ciò è stato dato che, dovrebbe essere nullo e se l'operazione fallisce, l'errore dovrebbe essere propagato all'utente perché l'applicazione dovrebbe generare un errore indicante che qualcosa è sbagliato nella distribuzione. Qualcuno è a conoscenza di best practice o standard in merito?

    
posta Prateek Jain 16.10.2018 - 21:32
fonte

2 risposte

1

Le eccezioni possono accadere anche in un buon codice (es .: Oh no, il server X è andato giù e non risponde ai tentativi di salvare in DB), quindi sono d'accordo che le eccezioni dovrebbero sempre essere propagate indietro.

Questo però non risponde alla domanda del tipo restituito. Esiste uno scenario in cui il codice del livello del database potrebbe decidere di NON salvare (la convalida avviene qui?) Se fosse restituito un tipo di ritorno significativo? Gli esempi potrebbero includere la mancanza di autorità per aggiornare quell'oggetto o un brutto bit di dati? Se si tratta di un semplice salvataggio OK vs eccezione, allora void è abbastanza accettabile come tipo di ritorno. Se è necessaria una sorta di risposta al codice motivo di errore, sarebbe opportuna una risposta non void, forse una enumerazione del codice di risposta.

Non è chiaro come sia "puro" il tuo design e se Update_in_DB accetti dati già validati e controllati per l'autorizzazione come pura azione DB o se ulteriori verifiche si verifichino in questa chiamata.

    
risposta data 24.10.2018 - 11:18
fonte
0

IMHO, ci sono due concetti diversi qui. Uno è se c'è qualcosa di significativo che dovresti tornare sul tuo metodo nel caso in cui l'aggiornamento abbia esito positivo e ciò dipende dal resto del flusso.

L'altro è come dovresti gestire un'eccezione generata nel processo di aggiornamento. In questo caso, la buona pratica di solito cattura l'eccezione e solleva un'altra, più significativa eccezione per consentire al client di gestire.

Ad esempio, un client potrebbe dover interrompere se si verifica un aggiornamento errato, altri potrebbero riprovare, un terzo potrebbe ignorarlo ...

Questo è il modo in cui generalmente lo gestisco, spero sia utile!

    
risposta data 23.10.2018 - 04:48
fonte

Leggi altre domande sui tag