Gracias netmentor por tus videos. Antes pensaba que el uso de dbcontext era acceder a la base de datos pero desde las últimas versiones he cambiado de opinión después de la refactorización una aplicación, monolito no obstante, que usaba muchas capas sobre ef en la que hemos mejorado mucho el rendimiento. Parece que ef es un desastre y lo primero que hacemos es encapsularlo meter capas y capas con sus propias entidades y mapeos por todos lados. Al final no usamos bien ef nos olvidamos como trackea las entidades y nos cargamos la potencia de linq y de ef a la primera de cambio.
Hola Iván, gracias por el vídeo, una pregunta, en el minuto 4.30 indicas que dbcontext hace de unit of work, cómo o dónde verifico esto? cómo saber que el dbcontext implementa uow? gracias por adelantado.
Pues porque funciona como tal, imagino que en la documentación oficial lo dirá, pero ni idea. UoW es un patrón y si algo funciona como ese patrón, técnicamente "implementa" UoW.
no creo que lo haga porque es bastante mas complejo (el blog lo tengo así) o bien inicias la conexión manualmente (para lo que necesitas una clase auxiliar que devuelva una conexion nueva o existente si ya esta abierta) o en el constructor. y para cerrar la conexión lo mismo, o la haces en el dispose o lo haces manualmente y necesitas comprobar todo, es un poco peñazo 😅
Si, con la poca informacion sobre UoW con Dapper que he encontrado se nota bastante que se acompleja mucho mas. Si ya lo tienes en el blog estaría buenísimo que lo compartieras en tu repositorio, solo la implementación de UoW claro. Saludos master, aprendo un montón con tus videos. @@NetMentor
Muchas gracias por el contenido, me ayuda mucho. Tengo una duda, entonces debes de crear diferentes UnitOfWork dependiendo el servicio que vayas a utilizar para incluir los Repository que necesite el servicio?
Muchísimas gracias por el vídeo, bueno por todos ellos, el contenido es de una calidad bestial. Sobre este en concreto, me surge una duda a la hora de aplicarlo. Siempre he trabajado con procedimientos almacenados para hacer transacciones que involucran modificaciones sensibles, pero si lo he entendido bien, este patrón podría hacer la misma función en la mayoría de los casos. Si es así, ¿Qué punto/s crees que son más críticos a la hora de elegir una opción o la otra? Imagino que en temas de rendimiento, SP debería ser mejor opción. Gracias de nuevo!
Entre el patrón Unit of Work y los procedimientos almacenados depende de varios factores, como la complejidad del proyecto, la mantenibilidad, la portabilidad y la reutilización del código. Si prefieres una arquitectura más flexible y fácilmente mantenible, el patrón Unit of Work puede ser una opción adecuada. Si tienes requisitos específicos de rendimiento o estás trabajando con un sistema heredado que ya utiliza SP, puede tener sentido utilizar procedimientos almacenados. Como siempre, evalúa las necesidades y características de tu proyecto antes de tomar una decisión. Y acuérdate que los procedimientos almacenados se ejecutan directamente en el motor de base de datos. Saludos!
Sí con unit of work pordías hacer lo mismo que con los SP. Muchas empresas, sobre todo las que empezaron en los 2000' utilizan SP, ya que UoW "no se habia inventado"; Y luego a la hora de elegirlo, pues bueno, en la bbdd siempre va a ir un poquitin más rápido, de eso no hay duda, pero si haces eso tienes lógica tanto en la base de datos, como en el código, lo que para mi es mucho peor. Personalmente en 2023 NUNCA elegiría tener lógica en la base de datos, quizá puedas jusitificar alguna consulta muy muy grande, pero yo no lo haría. y con respecto a SP de insertar, que tienen lógica dentro (ifs o swich, etc), es mucho mas dificil de mantener, de testear, etc. Si el sistema en el que trabajas ya esta así, pues tampoco hay mucho que hacer. muchas emprsas que conozco han intentado migrar y les lleva meses o incluso años debido a la cantidad de lógica que tienen en los SP
Hola Ivan me surgio una duda con respecto a lo que hablas desde el minuto 08:00 con IDisposable. Ya que siempre vamos a usar UnitOfWork por inyeccion de dependencias no se encargaria ya el contenedor del mismo de liberar la memoria con la conexion? Y en nuestro caso tal vez si tenemos que usar IDisposable no seria mejor usar IAsyncDisposable? Muchas gracias
si y no, osea si, porque lo hará, pero siempre que utilizas algo que utiliza IDisposable tienes que especificar el Idisposable y liberar las "dependencias"; al final es como todo, si tienes 10 llamadas por minuto "te da igual" porque "no se nota"; ahora, como subas a unos miles por minuto, la cosa cambia, o si utilizas serverless, que te cobran por uso de memoria, al final si no liberas bien con Idisposable te cuesta mas, que como digo, 10 llamadas por minuto, te da igual, mil por segundo, pues se nota. Pero vaya, que si usas una clase que usa IDisposable, hay que implementar IDisposable correctamente.
Tengo la duda: el ejm es un master - detail, pero no veo el inicio de la transaccion, que pasa si en el detalle hay un problema d integridad? se salva el encabezado sin el detalle? Gracias 🙏
a que te refieres de que no ves el inicio de la trasnacción? "el inicio de la transacción" es cuando instancias el DBContext. en unit of work o se guarda todo o no se guarda nada, un saludo
@@alexandrohdez3982 El DbContext usa transacciones de manera implícita al ejecutar el SaveChanges. Si no lo hiciera deberían declararse de manera explícita el inicio y el final de la transacción de manera explícita en la UnitOfWork
Lo malo es que cada vez que inyectas el UnitOfWork se inyectan todas las instancias de todos los repositorios en el constructor del UnitOfWork aunque no los necesites todos.
Qué bonito es ver contenido avanzado de C# en español
Estoy contigo.
Blog: www.netmentor.es/entrada/unit-of-work
Twitter: twitter.com/NetMentorTW
Gracias netmentor por tus videos. Antes pensaba que el uso de dbcontext era acceder a la base de datos pero desde las últimas versiones he cambiado de opinión después de la refactorización una aplicación, monolito no obstante, que usaba muchas capas sobre ef en la que hemos mejorado mucho el rendimiento. Parece que ef es un desastre y lo primero que hacemos es encapsularlo meter capas y capas con sus propias entidades y mapeos por todos lados. Al final no usamos bien ef nos olvidamos como trackea las entidades y nos cargamos la potencia de linq y de ef a la primera de cambio.
Muy bueno la verdad no tenia muy en claro este patron y como se lo implementaba. Muchas gracias por el contenido de calidad como siempre
muy bien explicado el video!! muchas gracias
Gracias por compartir!!
Hola Iván, gracias por el vídeo, una pregunta, en el minuto 4.30 indicas que dbcontext hace de unit of work, cómo o dónde verifico esto? cómo saber que el dbcontext implementa uow? gracias por adelantado.
Pues porque funciona como tal, imagino que en la documentación oficial lo dirá, pero ni idea. UoW es un patrón y si algo funciona como ese patrón, técnicamente "implementa" UoW.
@@NetMentor muchas gracias.
Buenísimo, me gustaría ver algún video de UoW con Dapper!
no creo que lo haga porque es bastante mas complejo (el blog lo tengo así)
o bien inicias la conexión manualmente (para lo que necesitas una clase auxiliar que devuelva una conexion nueva o existente si ya esta abierta) o en el constructor.
y para cerrar la conexión lo mismo, o la haces en el dispose o lo haces manualmente y necesitas comprobar todo, es un poco peñazo 😅
Si, con la poca informacion sobre UoW con Dapper que he encontrado se nota bastante que se acompleja mucho mas. Si ya lo tienes en el blog estaría buenísimo que lo compartieras en tu repositorio, solo la implementación de UoW claro.
Saludos master, aprendo un montón con tus videos. @@NetMentor
Gracias por tu video. Tengo una duda el metodo Dispose() nunca lo usas a pesar que lo implementas.
se llama automáticamente, tengo un vídeo de dispose por si tienes dudas th-cam.com/video/P-vSNkAHEHc/w-d-xo.html
@@NetMentor gracias
Muchas gracias por el contenido, me ayuda mucho. Tengo una duda, entonces debes de crear diferentes UnitOfWork dependiendo el servicio que vayas a utilizar para incluir los Repository que necesite el servicio?
no, con un únco unit of work es suficiente por aplicación.
Muchísimas gracias por el vídeo, bueno por todos ellos, el contenido es de una calidad bestial. Sobre este en concreto, me surge una duda a la hora de aplicarlo. Siempre he trabajado con procedimientos almacenados para hacer transacciones que involucran modificaciones sensibles, pero si lo he entendido bien, este patrón podría hacer la misma función en la mayoría de los casos. Si es así, ¿Qué punto/s crees que son más críticos a la hora de elegir una opción o la otra? Imagino que en temas de rendimiento, SP debería ser mejor opción. Gracias de nuevo!
Entre el patrón Unit of Work y los procedimientos almacenados depende de varios factores, como la complejidad del proyecto, la mantenibilidad, la portabilidad y la reutilización del código. Si prefieres una arquitectura más flexible y fácilmente mantenible, el patrón Unit of Work puede ser una opción adecuada. Si tienes requisitos específicos de rendimiento o estás trabajando con un sistema heredado que ya utiliza SP, puede tener sentido utilizar procedimientos almacenados. Como siempre, evalúa las necesidades y características de tu proyecto antes de tomar una decisión.
Y acuérdate que los procedimientos almacenados se ejecutan directamente en el motor de base de datos. Saludos!
Sí con unit of work pordías hacer lo mismo que con los SP.
Muchas empresas, sobre todo las que empezaron en los 2000' utilizan SP, ya que UoW "no se habia inventado"; Y luego a la hora de elegirlo, pues bueno, en la bbdd siempre va a ir un poquitin más rápido, de eso no hay duda, pero si haces eso tienes lógica tanto en la base de datos, como en el código, lo que para mi es mucho peor.
Personalmente en 2023 NUNCA elegiría tener lógica en la base de datos, quizá puedas jusitificar alguna consulta muy muy grande, pero yo no lo haría. y con respecto a SP de insertar, que tienen lógica dentro (ifs o swich, etc), es mucho mas dificil de mantener, de testear, etc.
Si el sistema en el que trabajas ya esta así, pues tampoco hay mucho que hacer. muchas emprsas que conozco han intentado migrar y les lleva meses o incluso años debido a la cantidad de lógica que tienen en los SP
¡Gracias!
Thanks
Hola Ivan me surgio una duda con respecto a lo que hablas desde el minuto 08:00 con IDisposable. Ya que siempre vamos a usar UnitOfWork por inyeccion de dependencias no se encargaria ya el contenedor del mismo de liberar la memoria con la conexion? Y en nuestro caso tal vez si tenemos que usar IDisposable no seria mejor usar IAsyncDisposable? Muchas gracias
si y no, osea si, porque lo hará, pero siempre que utilizas algo que utiliza IDisposable tienes que especificar el Idisposable y liberar las "dependencias"; al final es como todo, si tienes 10 llamadas por minuto "te da igual" porque "no se nota"; ahora, como subas a unos miles por minuto, la cosa cambia, o si utilizas serverless, que te cobran por uso de memoria, al final si no liberas bien con Idisposable te cuesta mas, que como digo, 10 llamadas por minuto, te da igual, mil por segundo, pues se nota.
Pero vaya, que si usas una clase que usa IDisposable, hay que implementar IDisposable correctamente.
Amigo, tienes el ejemplo del patron de repositorio y como ver este codigo, me puedes compartir si es posible. Saludos
Si
www.netmentor.es/entrada/repository-pattern
En el blog tienes un enlace q GitHub para ver el código
Tengo la duda: el ejm es un master - detail, pero no veo el inicio de la transaccion, que pasa si en el detalle hay un problema d integridad? se salva el encabezado sin el detalle? Gracias 🙏
a que te refieres de que no ves el inicio de la trasnacción? "el inicio de la transacción" es cuando instancias el DBContext.
en unit of work o se guarda todo o no se guarda nada, un saludo
@@NetMentor lo q me referia es el BeginTransaction, Commit y Rollback en caso de error. Gracias
@@alexandrohdez3982Hola buenas, ando viendo ese tema con el rollback. Pudiste aclarar las dudas y podrías explicarme?
@@alexandrohdez3982 El DbContext usa transacciones de manera implícita al ejecutar el SaveChanges. Si no lo hiciera deberían declararse de manera explícita el inicio y el final de la transacción de manera explícita en la UnitOfWork
Imagina lo que tardarias en hacer esto con 100 tablas o mas
si tienes 100+ tablas en una aplicación el menor de tus problemas es si usar UoW o el DbContext directamente
Lo malo es que cada vez que inyectas el UnitOfWork se inyectan todas las instancias de todos los repositorios en el constructor del UnitOfWork aunque no los necesites todos.
Es obligatorio hacerlo??
@@ilsondiaz425 hay técnicas para evitarlo como usar patrón singleton cuando se solicita el repo, en lugar de inyectarlos por constructor.
como complicarse la vida :v