Patrón de repositorio con capa de servicio: ¿demasiada separación?

Tengo un sitio MVC que usa el patrón de repositorio. No siento que esté usando el estilo MVC lo suficiente, así que me estoy preparando para rediseñar parte de él. Pero también quiero hacerlo, por lo que si el front-end cambia, será más fácil cambiarlo.

Esto es lo que tengo actualmente

Modelos: algunos de mis modelos contienen mis entidades / clases directamente. (El modelo de inicio de sesión contiene la clase Cliente, que es una correlación directa con la clase Tabla / repositorio del Cliente) Vistas: algunas de mis vistas contienen consultas de repositorio, es decir

_customerRepo.Query().FirstOrDefault(c => c.Login == User.Identity.Name);

Controladores: no es un gran problema aquí, los controladores llaman a algunas consultas de repositorio, y algunos de ellos también usan algunos servicios para llamar a los repositorios, es decir

_customerService.GetAllCustomers()

que llama

_customerRepo.Query().All();

Aquí están mis pensamientos:

1) Los modelos deben contener SOLO los datos necesarios para ser presentados en la vista. Incluso si todas las propiedades de la tabla / objeto del Cliente se presentan en la vista, deben reescribirse en su propio modelo / clase para que la vista no sepa nada sobre la arquitectura de la base de datos o los objetos de fondo

2) Las vistas solo deberían acceder a los objetos del modelo

3) (Y aquí es donde estoy luchando sobre qué camino tomar)

a) Los controladores (o en algún lugar del lado MVC, deben ser códigos que conviertan los datos del objeto devueltos por el repositorio / servicios y los conviertan en modelos. Supongo que podría colocar este código en un constructor de modelos. Pero yo ' noté que DI espera un constructor vacío predeterminado en caso de que haya errores de validación

b) Los controladores llaman a las interfaces de repos en métodos bien nombrados para recuperar datos (es decir, _customerRepo.GetAllCustomers ()

c) Los controladores SOLO acceden a una capa de servicio. La capa de servicio es lo único que interactúa con la capa de repositorio.

¿Estoy tratando de extraer demasiado el modelo, el controlador, el servicio y las capas de repositorio? ¿La capa de servicios es demasiado elevada ya que todo se puede hacer mediante repositorios?

¿Cuál es el enfoque recomendado para convertir los objetos / entidades comerciales a los modelos?

Sí, la capa de servicio es una sobrecarga si no tiene ninguna lógica de negocios allí. La arquitectura en capas parece una sobrecarga cuando una capa (en su caso, el servicio) no está haciendo mucho. Pero una arquitectura en capas proporciona un acoplamiento suelto que generalmente es bueno para adaptar los requisitos en el futuro.

Si puede garantizar que nunca necesitará hacer nada en la capa de servicio, excepto la copia de datos del repositorio al modelo, entonces puede eliminar la capa de servicio en su diseño. Sin embargo, si su aplicación es básica, entonces no tiene que preocuparse por agregar otra capa por rendimiento u otra razón.

Personalmente mantendré la capa de servicio y (dependiendo de la tecnología) implementaré una capa genérica DAO / Repository.

Depende de sus repositorios concretos, pero en términos generales, agregaría una capa de servicio en la parte superior de los repositorios.

Dependiendo de la implementación de su repositorio, pueden ser específicos de su almacén de persistencia. También facilita las pruebas y conduce a una arquitectura hexagonal, en lugar de una arquitectura en capas clásica (que considero un beneficio), consulte https://blog.8thlight.com/uncle-bob/2012/08/13/the- clean-architecture.html .

Para aclararle un poco qué es un controlador: MVC se remonta a cuando teníamos mainframes y aplicaciones de pantalla de texto. El Modelo era la información en el mainframe, la Vista era la pantalla del terminal y el Controlador era el teclado (presione # para manipular el modelo).

Las cosas han cambiado porque hoy en día usamos el mouse y los botones (para controlar la aplicación) se muestran en la vista.