asp.net-mvc - mvc - tag helpers asp net core 2
Repositorio en controlador o modelo? (5)
He estado trabajando con el Tutorial NerdDinner y la mayoría tiene sentido. De lo que no estoy seguro es de por qué el Repositorio se usa directamente en el Controlador y no en los objetos del Modelo. Por ejemplo, si queríamos implementar nuestro propio sistema de membresía y tenía un AccountController con un método de inicio de sesión, ¿cuál sería la mejor solución para conectarlo? p.ej
Login(username,password){
repo = AccountRepository
account = repo.getLogin(username,password)
//check account isn''t locked
//check account has been verified etc etc
//throw error or proceed to secure area
}
O
Login(username,password){
repo = AccountRepository
account = repo.getLogin(username,password)
account.login() //business logic is handled in Account (Model)
}
O
Login(username,password){
//no reference to repository
account = Account
//Account (Model) uses repository and handles business logic
account.login(username,password)
}
Estoy sugiriendo que el objeto Account use el AccountRepository directamente, en lugar de que AccountController obtenga la información del AccountRepository y luego la pase al objeto Account, por ejemplo
Estilo NerdDinnner:
1 solicitud de inicio de sesión entra
2 AccountController usa AccountRepository para obtener detalles de inicio de sesión según la solicitud
3 AccountController utiliza el objeto Cuenta y transfiere información desde el paso 1
4 Solicitud de proceso de objeto de cuenta y notificación a AccountController
Lo que sugiero
1 solicitud de inicio de sesión entra
2 AccountController utiliza el objeto Account para procesar el inicio de sesión según la solicitud
3 El objeto de cuenta utiliza AccountRepository para obtener detalles de inicio de sesión
4 Solicitud de proceso de objeto de cuenta y notificación a AccountController
La razón para este último estilo es que después de que los datos de inicio de sesión sean devueltos del AccountRepository, habrá reglas de negocio a seguir, por ejemplo, cuenta bloqueada, cuenta verificada, etc. Si se usa el primer estilo, la lógica para obtener los detalles y luego usarlos se divide más de 2 pasos. El último estilo mantiene toda la lógica unida mientras se usa el AccountRepository, por ejemplo
Account.Login(username,password){
repo = AccountRepository
account = repo.GetLogin(username,password)
//check account isn''t locked
//check account has been verified etc etc
//throw error or proceed to secure area
}
Espero que tenga sentido.
Al menos debe tener otra capa (no el controlador) que sea responsable de interactuar con una interfaz de repositorio. Thil permite cambiar de UI (el controlador es parte de él) por otro. De esta forma, no importa si se trata de una línea de comando, una interfaz de escritorio o web.
En ASP.NET MVC prefiero tener el modelo (no mi modelo de dominio, el MVC) en un proyecto separado, no en el de MVC. Esto permite compartir los DTO (el modelo MVC) con otro tipo de UI.
Diría que no es la cuenta la que realiza el inicio de sesión, sino que usa la cuenta para iniciar sesión en la aplicación , por lo que llamar al método de inicio de sesión en la cuenta parece un poco antinatural.
En el Diseño Dirigido por Dominio hay un lugar para la lógica de negocios que no encaja en la clase Cuenta: esto se llama servicio. Puede leer más sobre los servicios DDD, por ejemplo, aquí .
El "modelo" en mvc es un modelo de presentación, no un modelo de dominio. Puede considerar el modelo en MVC como un Objeto de Transferencia de Datos utilizado por el Controlador para alimentar el motor de visualización. El controlador es el único actor conectado con la capa de servicio.
El repositorio es una preocupación de infraestructura. Lo que está haciendo es hacer que su modelo dependa de su infraestructura. Esa es una especie de forma atrasada de hacerlo. Significa que si querías hacer cosas como usar inyección de dependencia, entonces tendrías que resolver tu modelo desde tu contenedor, lo cual no tiene mucho sentido para mí.
Además, el objetivo no es realmente mantener todo en un solo lugar. Debería esforzarse por mantener sus preocupaciones separadas en unidades lógicas. De esta manera, puede identificar fácilmente qué parte de la aplicación hace qué. También se presta para probar.
Evitaría poner su acceso a datos dentro de su modelo. Esto podría conducir a una dependencia en el modelo del mecanismo de almacenamiento. Por lo general, ubicaría esta lógica en la capa de servicio / lógica de negocios que hablaría con la capa de datos y los modelos. En su caso, con solo modelo y controlador, sería el controlador quien hace este trabajo.
Pienso en el modelo de dominio como un grupo de juguetes o herramientas, que recoges, usas, manipulas, etc. A los juguetes realmente no les importa dónde están almacenados, ni tampoco deberían. Deberías poder poner un juguete en el estante, o en una caja de herramientas. No afecta el juguete.