Una aplicación de software típica naturalmente necesitará acceder a algún tipo de almacén de datos para llevar a cabo operaciones CRUD (Crear, Leer...
For further actions, you may consider blocking this person and/or reporting abuse
Excelente post Eduardo, muchas gracias por compartir conocimiento.
Pero tengo una duda al respecto, en qué parte de la arquitectura recomendarías o debería ir interoperabilidades o consumo de servicios externos de la aplicación, de ante mano muchas gracias nuevamente.
Hola Leandro es un gusto saludarte, para cada problema existen múltiples maneras para resolver, personalmente te diría que podrías hacerlo dentro de la capa Services ya que está es la encargada de manipular los datos y su única responsabilidad es esa independientemente de si los datos vienen de una base de datos, archivos de texto, repositorios o servicios web que al final lo que trae todo lo anterior es información, por otro lado si quieres enfocarte en un desarrollo basado en muchas más capas podrías crear una capa que se encargue únicamente en consumo de servicios externos.
Excelente post Eduardo, muchas gracias por compartir esta información...
Realmente había estado buscando un post que explicará bien a detalle estos temas, sin embargo, solo encontraba puras fugas de información.
Me interesa mucho el tema, pues deseo cambiar las estructuras de mis proyectos, al leer tu post me di cuenta de alguna cosas que me hacían falta comprender bien, y algo que no me ha dejado dormir es lo que comentaste en las conclusiones...
"no es del todo necesario en estos días envolver Entity Framework Core en un patrón de Unidad de Trabajo, porque básicamente se está envolviendo una abstracción sobre una abstracción..."
¿Quieres decir que no es necesario usar UnitOfWork?
¿Entonces qué buena practica recomiendas para omitirlo o simplemente así como tal no usarlo?
De ante mano, muchas gracias nuevamente.
Hola Edgar de nada, con respecto a tu pregunta ¿Quieres decir que no es necesario usar UnitOfWork? yo te diría que no es necesario pero tampoco significa que no se pueda o deba hacer, todo depende de que necesitas y como prefieres atacar un problema, ya que si tu quieres desacoplar tus componentes para facilitar el desarrollo de pruebas unitarias y aprovechar la separación de responsabilidades adelante hazlo, y si no lo haces será muy difícil o casi imposible probar componentes y también seria ineficiente tener controllers con mucho código lo cuál también tendría como consecuencia que no podrías reutilizar código debido a que no esta centralizado.
En respuesta a esta pregunta.
¿Entonces qué buena practica recomiendas para omitirlo o simplemente así como tal no usarlo? todo depende del escenario en el que estés y que es lo que necesitas resolver, el patrón Repository y Unit Of Work son buenas prácticas, personalmente los utilizo para proyectos en producción y todo va bien en cuanto a escalabilidad, rendimiento y otros factores, pero existen infinidad de buenas prácticas que puedes combinar y ajustar según tus necesidades. Espero te sirva mi respuesta, saludos.
Muy bueno el aporte de Eduardo, me acaba de sacar de lios con este articulo, porque estaba realizando una implementacion de Patron de Repositorios, pero con una logic algo diferente ya que no utilizaba la clase UnitOdWork y se me estaba presentando problemas con algo llamadoHttpContext.GetOwinContext.Get.
Me gustaria realizar un pequeño aporte y es el siguiente: si lo que nos interesa es separar las capas del repositorio de la capa de aplicación (Controllers) me parece interesante poder agregar una capa de "Servicio" que me independice la lógica del negocio de la logica del controlador, de tal manera que se haga más facil el mantenimiento de la aplicación. por lo que yo agregaria una sección de Servicios, que se encargue de aplicar la lógica que se requiere para traer los datos requeridos al controlador, y que el controlador solamente se encargue de invocar el metodo del servicio que requiere (abstraccción)
Ejemplo
Metodo Get de AlbunessController solo invocaria el servicio
Service.ConsultaArtistaMayor(int anio)
y en la capa de servicio
crearía un método
public Task> ConsultaArtistaMayor(int anio) {
return await _genericRepository.GetAsync(a => 1.anio > anio, a =A a.OrderByDescending(b => b.anio),"Artista");
}
Al crear un repositorio de Artista por ejemplo como le inyectarias el context ?
yo trabaje un poco diferenten el Uow y el Generic asi que mi forma de inyectar no funciona, pero me gusta la forma quedaria segun tu planteamiento private readonly DBMCAContext _DbContext;
public ArtistaRepository(DbContext context) : base(context)
{
this._DbContext = context;
}
private readonly DBMCAContext _DbContext;
public ArtistaRepository(DBMCAContext context)
{
this._DbContext = context;
}
Buenas, como aseguras que la unit of work que injectas en el controlador, es la misma que se injecta en el repository? por lo que veo, no la estas declarando como singleton. saludos
¿Podría prescindir de la UnitOfWork e inclusive de EntityFrmework y trabajar directamente con ADO?
Buen post man! Saludos.-
Gracias. Saludos 😊