dove mettere la logica di validazione? In servizio o deposito?

Question

Ho un po 'di logica come questa, prima di salvare il magazzino nel db, controllerò se nel database ci sono le azioni con lo stesso codice. La mia domanda è dove dovrei inserire la logica, nel livello di servizio o nel livello del repository. ecco il codice di esempio:
Opzione 1: mettere nello strato servizio, ho messo il Metodo IsAccountAlreadyExists nello strato servizio

public override void Save(AccountInfo accountInfo) 
{ 
    using (var scope = new TransactionScope()) 
    { 
     if(this.IsAccountAlreadyExists(accountInfo)) 
     { 
      throw new AccountAlreadyExistedException(
       "Account Code : " + accountInfo.AccountCode + 
       " already existed."); 
     } 

     accountRepository.Save(accountInfo); 
      scope.Complete(); 
    } 
} 

opzione 2: Ti spostare le IsAccountAlreadyExists logica allo strato repository.

public override void Save(AccountInfo accountInfo) 
{ 
    try 
    { 
     using (var scope = new TransactionScope()) 
     { 
      accountRepository.Save(accountInfo); 
      scope.Complete(); 
     } 
    } 
    catch(AccountAlreadyExistedException e) 
    { 
     ... 
    } 
} 

Qual è la tua opinione?

Answer 1

Dato che hai chiesto opinioni, eccolo. :-) Inserisci la logica di convalida sul livello più basso più vicino ai dati. Quindi in questo caso, la logica dovrebbe essere nel repository. Il Servizio può intercettare l'Eccezione e tradurla, se lo desidera. Ma i criteri che "gli account dovrebbero essere unici" sono una caratteristica del repository, IMO.

Answer 2

Lo inserisco nel livello di servizio. Il repository gestisce la logica di persistenza.

È responsabilità del servizio chiamare altri oggetti per portare a termine il lavoro.

Answer 3

Preferisco inserire i controlli più vicini ai dati, quindi in questo caso sarebbe il database.

Farei un vincolo univoco basato sulle condizioni che si stanno facendo per garantire che l'account non esista. Ciò farebbe in modo che nessuno possa ignorare il mio livello intermedio e inserire dati non validi.

Quindi posso inserire il controllo nel livello repository come precauzione aggiuntiva.

Answer 4

Servizio: i modelli di esposizione possono essere un po 'soggettivi. Naturalmente ci sono esempi errati/completamente sbagliati là fuori (questo uno non è), ma il più delle volte, è solo una questione di preferenze personali.

Lo schema che tendo a seguire è che il livello di repository dovrebbe essere dedicato al 99% alle operazioni di lettura-scrittura-eliminazione con l'origine dati. L'unica validazione eseguita dal layer del repository è la validazione a basso livello sui modelli: in genere viene eseguita tramite un metodo Model.IsValid. Controlla solo i campi obbligatori e il formato/il contenuto di base di quei campi (ad esempio un controllo reg-ex di un campo che deve essere conservato e inviato per e-mail). Il livello del repository non tenta di dare un senso a questi errori: se il modello non è valido, genera un'eccezione e termina la sua gestione.

I controlli di business logic devono essere eseguiti nel livello di servizio. Se gli oggetti utente possono essere "assegnati" a un particolare modello ("Joe possiede il record X"), il livello di servizio deve eseguire i controlli per assicurarsi che a Joe sia consentito detenere quel record, ecc. Per essere completo, il mio livello di servizio in generale controlla anche il metodo IsValid sul modello, al fine di anticipare le eccezioni del livello dati.

Il mio unico commento con il tuo codice di esempio è con il nome del metodo "Salva" - questo è troppo ambiguo. Io preferisco Crea/Inserisci e Aggiorna - è chiaro allora che il primo risulterà in un nuovo record creato (nella misura in cui sovrascrivo il campo Id dell'oggetto con un nuovo valore), mentre quest'ultimo dovrebbe aggiornare un record, e quindi genererebbe un'eccezione se nessun valore Id viene passato.

Answer 5

Ritengo questo sia tre livelli (con un'interfaccia definita per collegare ogni pezzo):

• Data Repository - solo per memorizzare e recuperare dati grezzi. Come piccola logica va qui il più possibile.
• Business Model - tutte le intelligenze vanno qui, compresa la convalida.
• Servizio (ad esempio accesso client) - un pezzo molto sottile, quanto basta per fornire una connessione al client.

In questo modo, se si sceglie di memorizzare i dati in un altro modo, la logica di convalida non si perde con esso.

Analogamente, se si decide di fornire una diversa forma di accesso client, lo si fa senza la necessità di replicare un po 'di logica.