Progettazione libreria di classi CRUD, per restituire messaggi utili sull'errore di business logic, non eccezionale

Question

Sto costruendo una libreria CRUD di base, che prevedo di utilizzare in ambienti locali (aggiungi riferimento) e wcf (aggiungi riferimento servizio).

Quali sono i migliori tipi di restituzione per le parti Crea, Uupdate ed Elimina (che hanno regole di business più complesse) di una configurazione CRUD?

Desidero essere in grado di ridurre al minimo avanti e indietro sul filo, ma voglio anche fornire ai miei clienti informazioni significative su quando un'operazione non funziona correttamente, ma è tecnicamente valida (quindi non è un'eccezione).

Prendiamo ad esempio il CRUD per una classe Person, che ha questi campi: FirstName, MiddleName LastName e Date of Brith. Sono richiesti prima, ultimo e DOB, ma il centro non lo è.

Come devo riportare i guasti della logica aziendale al client? OSSIA "Devi specificare un valore per FirstName."

1. E 'questo in cui dovrei gettando eccezioni? (non mi sento come un caso eccezionale, quindi penso che non lo sia ma potrei sbagliarmi).
2. Devo usare void e un parametro "out"? Se sì, che tipo dovrebbe essere?
3. Devo utilizzare un tipo di ritorno dell'oggetto e inserire i dati in quello che succede?
4. Qualche altra opzione che mi è sfuggita completamente?

Answer 1

1.È questo dove dovrei generare eccezioni? (non mi sembra un caso eccezionale, quindi penso di no ma potrei sbagliarmi).

Personalmente, ritengo che si dovrebbe restituire un oggetto con un risultato così come eventuali errori di convalida, e non un'eccezione per la validazione dei dati, se questo è a causa di informazioni (convalida formato) o la convalida logica di business mancante. Tuttavia, io suggerisco di un'eccezione per gli errori che non sono legati ai dati in sé - vale a dire: se il database non commettere con dati validi, ecc

Il mio pensiero è che mancanza di convalida non è un "avvenimento eccezionale" . Personalmente ritengo che tutto ciò che un utente può rovinare semplicemente inserendo dati sufficienti/corretti/ecc. È qualcosa che non è eccezionale - è una pratica standard, e dovrebbe essere gestita direttamente dall'API.

Le cose non correlate a ciò che l'utente sta facendo (ad es. Problemi di rete, problemi del server, ecc.) Sono eventi eccezionali e garantiscono un'eccezione.

2. Dovrei utilizzare void e un parametro "out"? Se sì, che tipo dovrebbe essere?

3. Dovrei utilizzare un tipo di ritorno dell'oggetto e inserire i dati in quello che succede?

Personalmente preferisco la terza opzione. i parametri "out" non sono molto significativi. Inoltre, desideri restituire più di una singola informazione di stato da questa chiamata: ti consigliamo di restituire informazioni sufficienti per contrassegnare le proprietà appropriate come non valide, oltre a tutte le informazioni sull'intero funzionamento.

Probabilmente richiederà una classe che contenga almeno uno stato di commit (successo/formato non riuscito/logica aziendale non riuscita/ecc.), Un elenco di mappature per proprietà-> errori (es .: IDataErrorInfo informazioni di stile) e potenzialmente un elenco di errori che non sono legati a una proprietà specifica, ma riguardano piuttosto la logica di business dell'operazione nel suo complesso o la combinazione di valori di proprietà suggeriti.

4. Qualche altra opzione che ho perso completamente?

L'altra opzione, che mi piace un po ', è quella di avere la convalida in un assembly separato dal livello di elaborazione aziendale. Ciò consente di riutilizzare la logica di convalida sul lato client.

Il bello di questo è che è possibile semplificare e ridurre drasticamente il traffico di rete. Il cliente può pre-validare le informazioni e inviare solo i dati attraverso il filo se è valido.

Il server può ricevere i dati validi e riconvalidarli e non restituire altro che un singolo risultato di commit. Credo che questo dovrebbe avere almeno tre risposte: successo, non riuscita a causa della logica di business o non riuscita a causa della formattazione. Questo dà sicurezza (non devi fidarti del client) e dà al cliente informazioni su ciò che non viene gestito correttamente, ma evita di passare entrambe le informazioni errate da client-> server e le informazioni di convalida da server-> client, quindi può ridurre drasticamente il traffico.

Il livello di convalida può quindi (in modo sicuro) inviare le informazioni al livello CRUD da inviare.

Answer 2

È possibile trovare questo post sul blog di Rob Bagby interessante; descrive come implementare un repository per gestire le operazioni CRUD e, al punto, specificamente come implementare la validazione, restituendo una raccolta di "RuleViolation" al client nel caso ci fosse un problema.

http://www.robbagby.com/silverlight/patterns-based-silverlight-development-part-ii-repository-and-validation/

[modifica] Per me, si tratta di un caso per un'eccezione: se la creazione di un utente richiede un nome e il nome non viene fornito, il chiamante non ha utilizzato gli argomenti propri, e non sta usando il metodo nel modo previsto. InvalidArgumentException sembra adeguato.

Answer 3

Si dovrebbe verificare l'implementazione di Validation Rules di Rocky Lhotka nel suo CSLA framework.

NOTA: ho fatto non dire di usare il suo quadro in massa, in quanto ha alcuni problemi di accoppiamento che non si rompono alcuni sforzi SRP nelle ultime tendenze di sviluppo .NET.

Tuttavia, il suo framework utilizza la notifica "automatica" fino al livello dell'interfaccia utente e l'integrazione con i messaggi di errore di convalida con supporto per i controlli Web/Winform.

Answer 4

Edit: Devo notare, vorrei normalmente la roba di validazione astratta in un livello aziendale, che gestisse la convalida e chiamasse i metodi CRUD dopo che la convalida aveva avuto successo.

Un modo per procedere sarebbe quello di restituire una classe di "risposta" che contiene tutte le informazioni che un utente della tua biblioteca dovrebbe valutare cosa è successo e cosa fare dopo.Un esempio molto semplice di una classe si potrebbe usare sarebbe qualcosa di simile a questo:

public class Response<T> where T:BusinessObject 
{ 
    public Response(T oldOriginalValue, T newValue) 
    { 
    } 

    /// <summary> 
    /// List of Validation Messages 
    /// </summary> 
    public List<ValidationMessage> ValidationMessages { get; set; } 

    /// <summary> 
    /// Object passed into the CRUD method 
    /// </summary> 
    public T OldValue { get; private set; } 

    /// <summary> 
    /// Object passed back from the CRUD method, with values of identity fields, etc populated 
    /// </summary> 
    public T NewValue { get; private set; } 

    /// <summary> 
    /// Was the operation successful 
    /// </summary> 
    public bool Success { get; set; } 
} 

public class ValidationMessage 
{ 
    /// <summary> 
    /// Property causing validation message (i.e. FirstName) 
    /// </summary> 
    string Property { get; set; } 

    /// <summary> 
    /// Validation Message text 
    /// </summary> 
    string Message { get; set; } 
} 

Answer 5

Il dibattito tra il ritorno di una struttura risultato con i dettagli del fallimento contro un'eccezione può essere generalizzato a "Posso eseguire con successo l'richiesto azione?" Stai progettando una libreria e il modo in cui la libreria comunica le modalità di errore fa parte di questo.

Se alla libreria viene richiesto di creare un oggetto Utente ma non è possibile perché la convalida del nome utente non è riuscita, è possibile restituire un utente vuoto insieme ai messaggi di errore di convalida e sperare che il codice client verifichi il valore restituito. La mia esperienza (flashback pre-ATL DCOM) con il dover testare i valori di ritorno per i codici di errore è che è facile ottenere compiacenti (o pigri) e saltarli.

Da ciò che hai descritto, l'utilizzo di eccezioni non è fuori questione. Definisci un'eccezione genitore per tutti i tipi di eccezioni che la tua biblioteca può lanciare. In questo modo i client non devono includere un ampio elenco di eccezioni secondarie a meno che non lo desiderino davvero. Un esempio di questo è SqlException.

Answer 6

Per motivi di prestazioni, la convalida dell'input iniziale deve essere eseguita nel livello client. (es .: non preoccuparsi di inviare dati errati lungo il filo.) Nel livello client, un errore di validazione dell'input sarebbe, in effetti, un problema molto prevedibile che non dovrebbe generare eccezioni. Tuttavia, se si applica questa convalida "anticipata" sul livello client, un errore di convalida dei dati riscontrato in qualsiasi livello più profondo potrebbe essere ragionevolmente considerato come un problema imprevisto, pertanto l'attivazione di eccezioni per errori di convalida dei dati in tali livelli non sarebbe inappropriata.