Cosa devo restituire dai livelli di servizio o quasi da qualsiasi metodo

Question

L'unica cosa che può ancora ottenere è cosa restituire dai metodi? So che si dovrebbe essere il più specifici possibile (cioè non restituiscono oggetto se è necessario restituire un int)

Tuttavia è casi come questo

Ho un livello di servizio che contiene la logica di business. Dire che ho un metodo chiamato CreateAnEvent()

Fondamentalmente si salva un evento per il database e in caso di successo si restituirà una stringa con "salvati su database"

Ora, cosa succede se ho bisogno di controllare se questo l'evento incontra alcune regole aziendali.

1. Non può essere inferiore alla data odierna.
2. Non può essere maggiore di una settimana da oggi.
3. Impossibile creare il venerdì.

Qualcosa di simile in cui ho bisogno di fare prima alcune verifiche di business che potrebbe o portare ad errori di convalida o forse una sorta di altro errore (forse anche un'eccezione) o di un messaggio di successo ancora mi ottiene ciò che dovrei ritornerò .

Quindi, prima di procedere con la convalida. Dite che l'utente fallisce tutte queste regole di validazione e ora? Sto restituendo una stringa in modo che questo non sia carino, dovrò usare csv per restituire tutti gli errori e analizzarli.

Quindi sembra davvero pessimo.

Potrei prima avere un metodo separato chiamato Validate() ma ora devo ricordarmi di chiamarlo prima di chiamare CreateAnEvent(). Quindi non penso che sia fantastico.

Sto usando ViewModels nel mio progetto mvc, quindi forse dovrei passare l'intero viewModel al livello di servizio e quindi restituire questo ViewModel.

In questo modello di vista potrei avere una raccolta di errori che potrei aggiungere tutti questi errori e una stringa per contenere un messaggio di successo.

Una volta che viene restituito, basta fare un controllo prima di eventuali errori se il conteggio è zero, quindi si presume che il messaggio di successo sia stato riempito.

Non sto restituendo il tipo più specifico indietro ma risolverebbe il mio problema. Tuttavia, non penso che il livello di servizio debba sapere qualcosa su un viewModel.

So che alcune persone eseguono la convalida nel viewmodel ma ritengo che più per le regole di base della logica non business è un campo vuoto o no. Non penso che dovrei fare test come ho descritto sopra in un modello view.

Quindi l'ultima opzione che posso pensare è inviare il modello di dominio (che sarebbe in un viewmModel poiché ci sono buone probabilità che lo utilizzerei nella vista) e in questo modello di dominio vorrei aggiungere una stringa per i messaggi di successo e una raccolta di errori.

Vorrei quindi restituire questo modello di dominio.

Quindi è praticamente la stessa idea di utilizzare ViewModels ma questa volta estraendo il modello di dominio e utilizzandolo.

Quindi questo è il modo migliore per farlo o ci sono modi migliori?

Answer 1

Preferisco separare la logica di convalida in classi proprie. La ragione di ciò è che le entità possono avere vari livelli di validazione. Le mie lezioni validatore implementano la seguente interfaccia:

public interface IValidator<T> 
{ 
    bool IsValid(T entity); 
    IEnumerable<string> BrokenRules(T entity); 
} 

Ho poi iniettare questo validatore al mio servizio. Il servizio può quindi restituire un valore booleano se il metodo ha esito positivo/negativo. In caso di guasti è disponibile l'informazione aggiuntiva contenuta nella 'BrokenRules' enumerable. Ho documentato questo in un post del blog:

http://blog.bobcravens.com/2010/09/the-repository-pattern-part-2/

fatemi sapere se avete domande. Spero che questo ti aiuti.

Bob