¿Qué debo devolver de las capas de servicio o de casi cualquier método?

Question

Lo único que todavía me puede hacer es ¿qué devolver de los métodos? Sé que debe ser lo más específico posible (es decir, no vuelven objeto si necesita devolver un int)

Sin embargo, es casos como este

tengo una capa de servicio que contiene la lógica de negocio. Decir que tengo un método llamado CreateAnEvent()

Básicamente se ahorra un evento a la base de datos y si tiene éxito, devolverá una cadena con "guardado en la base de datos"

Ahora qué sucede si primero tengo que comprobar si este evento cumple con algunas reglas de negocios.

1. No puede ser menor que la fecha de hoy.
2. No puede ser mayor a una semana a partir de hoy.
3. No se puede crear un viernes.

Algo así donde primero tengo que hacer comprobaciones comerciales que pueden llevar a errores de validación o tal vez algún otro error (tal vez incluso una excepción) o un mensaje de éxito me devuelve lo que debería devolver .

Así que vamos primero con la validación. Supongamos que el usuario falla todas estas reglas de validación ¿y ahora? Estoy devolviendo una cadena, por lo que no será bonito, tendré que usar csv para devolver todos los errores y analizarlos.

Así que eso parece muy malo.

Primero podría tener un método separado llamado Validate() pero ahora tengo que recordar llamar esto antes de llamar a CreateAnEvent(). Entonces no creo que esto sea tan bueno.

Estoy usando ViewModels en mi proyecto de mvc, así que tal vez debería pasar todo el modelo de vista a la capa de servicio y luego devolver este ViewModel.

En este modelo de vista podría tener una colección de errores a los que podría agregar todos estos errores, así como una cadena para contener un mensaje de éxito.

Una vez que se devuelve simplemente haga primero una comprobación de errores si el recuento es cero y suponga que se llena el mensaje de error.

No devolveré el tipo más específico, pero solucionaría mi problema. Sin embargo, no creo que la capa de servicio deba saber nada sobre viewModel.

Sé que algunas personas hacen la validación en el modelo de vista, pero considero que más para las reglas básicas de lógica no empresarial como es un campo en blanco o no. No creo que deba hacer las pruebas como describí anteriormente en un modelo de vista.

Así que la última opción que puedo pensar es enviar el Modelo de Dominio (que estaría en un modelo viewm ya que hay una buena posibilidad de que lo use en la vista) y en este Modelo de Dominio agregaría una cadena para mensajes de éxito y una colección de errores.

Devolvería este modelo de dominio.

Por lo tanto, es básicamente la misma idea que usar ViewModels, pero esta vez extrayendo el modelo de dominio y usándolo.

¿Es esta la mejor manera de hacerlo o hay mejores formas de hacerlo?

Answer 1

Prefiero separar mi lógica de validación en clases propias. La razón para esto es que las entidades pueden tener varias capas de validación. Mis clases de validador implementan la siguiente interfaz:

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

Luego, inserto este validador en mi servicio. El servicio puede devolver un valor booleano si el método tiene éxito/falla. En caso de fallas, la información adicional contenida en el enumerable 'BrokenRules' está disponible. He documentado esto en una entrada de blog:

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

que me haga saber si tiene alguna pregunta. Espero que esto ayude.

Bob