De qué manera es mejor: haga su propio envoltorio para DbContext o use DbContext en Controller

asp.net-core asp.net-core-mvc c# entity-framework-core

Pregunta

En mi proyecto, uso entidad framework 7 y asp.net mvc 6 \ asp.net 5 . Quiero crear CRUD para modelos propios.

¿Cómo puedo hacerlo mejor?

  1. Utilice dbcontext desde el controlador. En el siguiente enlace, el autor explica que es mejor así, pero ¿es correcto para los controladores?
  2. Hacer envoltorio propio. Las Mejores prácticas escriben sobre lo que es mejor hacer su propio repositorio.

No cambiaré la eficacia en otra cosa, así que no me importa, incluso si existe una fuerte conectividad para acceder a los datos desde una implementación en particular y sé que en ef7 dbcontext implementó inmediatamente la Unidad de trabajo y los patrones del repositorio.

Respuesta aceptada

La respuesta a su pregunta se basa principalmente en la opinión. Nadie puede decir definitivamente "una forma es mejor que la otra" hasta que se contesten muchas otras preguntas. ¿Cuál es el tamaño / alcance / presupuesto de su proyecto? ¿Cuántos desarrolladores estarán trabajando en ello? ¿Solo tendrá controladores MVC (basados ​​en la vista), o también tendrá controladores API (basados ​​en datos)? Si es lo último, ¿cuánto se superpondrá entre los métodos de acción MVC y API, si los hay? ¿Tendrá algún cliente que no sea web, como WPF? ¿Cómo planeas probar la aplicación?

Entity Framework es una herramienta de capa de acceso a datos (DAL). Los controladores son herramientas de manejo de solicitud y respuesta del cliente HTTP. A menos que su aplicación sea CRUD puro (lo cual es dudoso), probablemente habrá algún tipo de procesamiento de lógica de negocios que deberá realizar cuando reciba una solicitud web a través de HTTP y cuando guarde los datos de la solicitud en una base de datos usando EF ( el campo X es obligatorio, si proporciona datos para el campo Y también debe proporcionar datos para el campo Z, etc. Por lo tanto, si usa el código EF directamente en sus controladores, esto significa que su lógica de procesamiento de negocios seguramente estará presente en los controladores junto con ellos.

Aquellos de nosotros que tenemos una experiencia decente en el desarrollo de aplicaciones no triviales con .NET tendemos a desarrollar opiniones de que los negocios y la lógica de acceso a los datos no deben estar presentes en los controladores debido a ciertas dificultades que surgen cuando se implementa dicho diseño. Por ejemplo, cuando coloca la lógica de solicitud y respuesta web / http, junto con la lógica de negocios y la lógica de acceso a datos en un controlador, termina teniendo que probar todos esos aspectos de la aplicación a partir de las propias acciones del controlador (lo cual es una violación manifiesta de la Principio de Responsabilidad, si te importa el diseño SOLID). También digamos que desarrolla una aplicación MVC tradicional con controladores que devuelven vistas, luego decide que desea extender la aplicación a otros clientes como iOS / android / WPF / o algún otro cliente que no entienda sus vistas MVC. Si decide implementar un conjunto secundario de acciones de controlador basado en datos WebAPI, duplicará la lógica de acceso a datos y negocios en al menos 2 lugares.

Aún así, esto no toma la decisión de mantener toda la lógica de acceso a datos y negocios en los controladores intrínsecamente "peor" que un diseño alternativo. Cualquier decisión que tome al diseñar la arquitectura de una aplicación web tendrá ventajas y desventajas. Siempre habrá concesiones sin importar la ruta que elija. Las ventajas de mantener todo el código de su aplicación en los controladores pueden incluir un menor costo, complejidad y, por lo tanto, tiempo de comercialización. No tiene sentido sobre-diseñar arquitecturas complejas para aplicaciones muy simples. Sin embargo, desafortunadamente, nunca tuve el placer de desarrollar una aplicación simple, por lo que estoy en la opinión generalizada de que mantener el código de acceso a datos y negocios en los controladores "probablemente no" es una buena decisión de diseño a largo plazo.

Si realmente estás interesado en alternativas, te recomendaría leer estos dos artículos . Son un buen manual sobre cómo se podría implementar un patrón de comando y consulta (CQRS) que los controladores puedan consumir. EF implementa los patrones de unidad de trabajo y el repositorio fuera de la caja, pero eso no significa necesariamente que deba "ajustarlo" para mover el código de acceso a los datos fuera de sus controladores. Mucha suerte tomando este tipo de decisiones para su proyecto.

public async Task<ActionResult> Index() {
    var user = await query.Execute(new UserById(1));
    return View(user);
}

Respuesta popular

Por lo general, prefiero usar el patrón de Repository junto con el patrón UnitOfWork ( http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository -y-unidad-de-patrones-de-aplicación-en-un-asp-net-mvc-application ) - Instalo DbContext en un objeto de instancia UnitOfWork e inyecto DbContext en los repositorios. Después de eso, he creado una instancia de UnitOfWork en el controlador y el controlador no sabe nada acerca de DbContext:

public ActionResult Index()
{
    var user = unitOfWork.UsersRepository.GetById(1); // unitOfWork is dependency injected using Unity or Ninject or some other framework
    return View(user);
}



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué