trabajo - repositorio base c#

Capas y repositorios de servicio

Question

He estado utilizando frameworks MVC 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 de 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 las personas mantienen sus controladores y modelos delgados al tener una capa de servicio, que me gusta.

Solo intento entender cómo una capa de servicio y un repositorio deberían funcionar 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 no es necesario realizar ninguna manipulación en los datos y, por lo tanto, no es necesario que se involucre una capa de servicio.
2. Una vez que se necesita hacer algún trabajo con los datos (lógica de negocios), esto se debe hacer en la capa de servicio y el controlador realizará una simple llamada a la capa de servicio cuando sea necesario.
3. Una vez que un servicio ha hecho su lógica comercial, usará el repositorio según sea necesario (si es necesario conservar los datos).
4. Los modelos idealmente deberían mantenerse esbeltos, idealmente las actuaciones 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 de 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 la responsabilidad única, por lo tanto, tratando de resolver mis prácticas de codificación.

Gracias

Answer 1

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

Answer 2

Primero, no hay un conjunto de reglas que funcionen en cada situación. La forma en que modele su aplicación depende en gran medida del tipo y la complejidad del proyecto. Habiendo dicho eso, estas son algunas ideas:

1. No hay nada malo con 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 lógica comercial, 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. No hay 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 es hacer lo que se siente bien (esa suele ser la respuesta correcta).

Answer 3

This video proporciona una gran idea 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.