Service Layers and Repositories

Question

He estado utilizando MVC frameworks por un tiempo corto y realmente me gusta cómo se separan las preocupaciones. Tengo la mala costumbre de dejar que los controladores hagan bastante trabajo. Así que realmente estoy buscando algunos consejos.

Cuando comencé a usar MVC con bastante frecuencia, el controlador estaba manipulando los modelos después de que se había hecho el trabajo en la base de datos. Sabía que esto era malo, así que cambié ese trabajo a los modelos. Sin embargo, no estoy contento con eso porque quiero que mis modelos sean muy inteligentes.

He leído un poco y veo que la gente mantiene sus controladores y modelos delgados al tener una capa de servicio, que me gusta.

Estoy tratando de entender cómo una capa de servicio y un repositorio deberían funcionar todos juntos. Aquí están mis suposiciones, ¿pueden decirme si esta es una buena forma de trabajar?

1. El controlador puede llamar al repositorio directamente si hay manipulación que hay que hacer en los datos y como una capa de este tipo de servicios no necesita involucrarse
2. Una vez que cualquier trabajo que hay que hacer con los datos (la lógica de negocio) entonces esto debe hacerse en la capa de servicio y el controlador hará una simple llamada a la capa de servicio cuando sea necesario
3. Una vez que un servicio haya hecho su lógica de negocios, usará el repositorio según sea necesario (si los datos necesitan persistir).
4. Los modelos idealmente deben mantenerse esbeltos, idealmente actúan como nada más que DTOs
5. La validación de los datos se realizará dentro de los modelos (utilizando los atributos de validación MonoRail). Aprecio que ni a uno le guste contaminar sus modelos con muchos atributos, pero esa es una discusión diferente. Me gusta el beneficio de los atributos de validación de MonoRail para la validación jQuery automática en la UI.

Estoy tratando de convertir todo mi código en el principio de responsabilidad única, por lo tanto, tratando de resolver mis prácticas de codificación.

Gracias

Answer 1

En primer lugar, no existe un conjunto de reglas que va a trabajar en cada situación. La forma en que modele su aplicación depende en gran medida del tipo y la complejidad del proyecto. Una vez dicho esto, he aquí algunas ideas:

1. No hay nada de malo en llamar al repositorio desde un controlador. Solo asegúrese de que el controlador no contenga lógica comercial.
2. El servicio se ocupa de (algunos) lógica de negocios y utiliza otros servicios para hacerlo. El repositorio es un tipo de servicio, no hay nada de malo en llamarlo desde un servicio.
3. El modelo debe contener la lógica de negocio, en realidad siempre debe intentar ponerlo en el modelo primero. Si necesita datos externos para realizar esa lógica comercial (desde otro modelo o desde el repositorio), entonces debe crear un servicio.
4. Nada malo con la validación en los modelos. Usar atributos o no es una cuestión de gusto (si te gusta, entonces está bien). Mueva la validación fuera del modelo si se vuelve demasiado complejo (cree un conjunto externo de reglas).

Lo más importante, haz lo que te parezca correcto (esa suele ser la respuesta correcta).

Answer 2

Ian Cooper acaba de escribir una publicación de blog llamada The Fat Controller solo con este tema.

Answer 3

This video ofrece una gran visión de cómo organizar su solución asp.net MVC y abordar la separación de preocupaciones, y una mejor capacidad de prueba. Espero que ayude a alguien más también. Aprendí algunas cosas buenas de eso.