Hola, yo tengo muchos años programando, por eso soy mas de la vieja escuela y si uso muchos procedimientos, trabajo la lógica dentro de la base y gestiono en el backend, que me tardo mas programando puede ser, pero tengo un control absoluto, pero eso es mi punto de vista se que ahora se usa mas EF porque facilita mucho la vida. Pero igual recomiendo que usen mas precedure , functions (de tabla y de valores) y triggers por lo menos al principio para que entiendan como funcionan y vean cuando usar uno o cuando usar otro y que esta haciendo por detrás EF
Muchas gracias por tus tutoriales. Yo los utilizo. Tengo un proyecto con un FrontEnd en Net con Blazor que utiliza un Backend con EF que gestiona todas las apis. La BD es Postgres. Cuando alguna gestión (mas o menos compleja) tarda mas de 10 segundos genero un procedimiento almacenado para optimizar tiempos. Muchas gracias por enseñarme tanto. Saludos
creo que hay una confucion dices que fromsql esta en desuso pero veo que en la documentacion dice esto, FromSql se introdujo en EF Core 7.0. Si utiliza versiones anteriores, utilice FromSqlInterpolated en su lugar. y tambien ley que fromsqlRaw fue que quedo en desuso
En la empresa para la cual trabajo no quieren usar store procedures, pero para identificar rapidamente de donde salen los querys en la cadena de conexion mando el nombre del microservicio, servicio, api/metodo para agilizar la busqueda
Al usar procedimientos almacenados al igual que cualquier pieza de código, debemos tener cuidado de usar las mejores prácticas, por que suelen llegar a crecer y se vuelven tediosos de mantener, solo es una opinión personal he visto unos procedimientos de más de 5000 lineas 😕
No soy muy fan de los sps, pero cusndo toca toca, lo que uso para determinar si va a sp, es rendimiento, si son muchas cosas de un somo flujo voy al sp. Si es algo mas separado uso código, aparte q depurar es mas fácil en codigo..
Saludos Iván. Gracias por el vídeo y felicidades por tu nuevo libro! ¿Qué tal sobre las Unit of Work, qué tan útiles son? ¿En comparación con las transacciones las reemplazarán? ¿Tienes algún contenido sobre el mismo?
Hola, la empresa para la que hice un proyecto usan bastante los procedimientos de tal forma que las modificaciones en la logica de negocio esta allí, ademas que el jefe de sistemas maneja mejor los datos en sql.
¿En EF si haces una proyección en una class anónima mapeando los campos que necesitas? No te construye un select con solo las columnas correspondientes ?
@@NetMentor Pues me dejas de piedra. Siempre he pedido a todos que se hagan proyecciones en DTO, o en anónimas para consultas internas. Esa es una de sus gracias
Algo que pudiera agregar es, que falsamente estamos creyendo que no debemos topar la BD esto por el uso de los ORM (Moda) el motor de su forma nativa funcionará mejor con lo suyo, por eso los ERP's de largo siguen usando SP, cierto es que los ORM han mejorado mucho en su funcionamiento, pero, la forma en que funciona un motor de BD es que al hacer una consulta, la analiza y en ese momento la "compila" esto en transacciones emprersariales es costo de servidor, mientras que un SP se precompila (Ya conoce y sabe lo que debe hacer, por eso simplemente la ejecuta, en lugar de analizar un query ver que trae y luego de eso ejecutar). Donde la lógica es compleja, conviene de largo usar los SP, mientras que en un simple crud, si nos sirve mucho los ORM.
Hola, muy bueno el video. ¿Cuál sería el mejor enfoque para mantener la creación de los SP dentro de las migraciones? Porque de esta forma no se generará automáticamente esos procesos/funciones al momento de inicializar la aplicación.
@@NetMentor Gracias por la respuesta!!! Mi duda radicaba más que nada en el versionado de las migraciones y en la facilidad para el despliegue. He probado de crear una migración sin ningun cambio en el modelo, de forma tal que el "up" y el "down" queden vacíos y luego completarle el código de los SP con la ejecución del CREATE PROCEDURE y el DROP PROCEDURE a mano. Es algo que funciona pero no del todo prolijo. Pensé que tal vez estaba resuelto de alguna forma por el Framework. Muchas gracias!
El tema de los StoreProcedures es muy polémico, hay quienes de plano los ignoran y "satanizan" su uso sobre todo en comunidades de Java dejando la base de datos como mero contenedor de tablas desperdiciando el potencial de las funciones y, justo los SProcedures, en lo personal yo prefiero el extremo opuesto, delegar la mayor parte de la lógica de negocio al Sistema Gestor de Bases de datos y hacer llamadas a los SPs desde el código.
El mayor problema de dejar lógica en los SPs es que muy comunmente se ignoran los tests de los propios procedures, asi que a la larga "cuesta" mas querer hacer un cambio. Yo personalmente prefiero tener la lógica en código, pero hay situaciones donde es mucho mejor tenerla en SQL.
Twitter: x.com/NetMentorTW
Blog: www.netmentor.es/entrada/sored-procedures-entity-framework-core
Te felicito por el libro y por el contenido de tus videos
Hola, yo tengo muchos años programando, por eso soy mas de la vieja escuela y si uso muchos procedimientos, trabajo la lógica dentro de la base y gestiono en el backend, que me tardo mas programando puede ser, pero tengo un control absoluto, pero eso es mi punto de vista se que ahora se usa mas EF porque facilita mucho la vida. Pero igual recomiendo que usen mas precedure , functions (de tabla y de valores) y triggers por lo menos al principio para que entiendan como funcionan y vean cuando usar uno o cuando usar otro y que esta haciendo por detrás EF
Muy buen video 👏👏. Me ayudo mucho
Muchas gracias por tus tutoriales.
Yo los utilizo.
Tengo un proyecto con un FrontEnd en Net con Blazor que utiliza un Backend con EF que gestiona todas las apis.
La BD es Postgres.
Cuando alguna gestión (mas o menos compleja) tarda mas de 10 segundos genero un procedimiento almacenado para optimizar tiempos.
Muchas gracias por enseñarme tanto.
Saludos
Buen video! Ya me respondiste a lo que me preguntaba porque las empresas ya no usaban tanto StoreProcedures!
creo que hay una confucion dices que fromsql esta en desuso pero veo que en la documentacion dice esto, FromSql se introdujo en EF Core 7.0. Si utiliza versiones anteriores, utilice FromSqlInterpolated en su lugar. y tambien ley que fromsqlRaw fue que quedo en desuso
En la empresa para la cual trabajo no quieren usar store procedures, pero para identificar rapidamente de donde salen los querys en la cadena de conexion mando el nombre del microservicio, servicio, api/metodo para agilizar la busqueda
Al usar procedimientos almacenados al igual que cualquier pieza de código, debemos tener cuidado de usar las mejores prácticas, por que suelen llegar a crecer y se vuelven tediosos de mantener, solo es una opinión personal he visto unos procedimientos de más de 5000 lineas 😕
No soy muy fan de los sps, pero cusndo toca toca, lo que uso para determinar si va a sp, es rendimiento, si son muchas cosas de un somo flujo voy al sp. Si es algo mas separado uso código, aparte q depurar es mas fácil en codigo..
Saludos Iván. Gracias por el vídeo y felicidades por tu nuevo libro! ¿Qué tal sobre las Unit of Work, qué tan útiles son? ¿En comparación con las transacciones las reemplazarán? ¿Tienes algún contenido sobre el mismo?
tengo un vídeo de unit of work en este mismo curso -> ua-cam.com/video/SGG6dNFtuCs/v-deo.html
Hola, la empresa para la que hice un proyecto usan bastante los procedimientos de tal forma que las modificaciones en la logica de negocio esta allí, ademas que el jefe de sistemas maneja mejor los datos en sql.
¿En EF si haces una proyección en una class anónima mapeando los campos que necesitas? No te construye un select con solo las columnas correspondientes ?
Si, pero quien hace eso?
El 99% de gente utiliza la entidad de la tabla en si, así que el select contiene todos los campos
@@NetMentor Pues me dejas de piedra. Siempre he pedido a todos que se hagan proyecciones en DTO, o en anónimas para consultas internas. Esa es una de sus gracias
cómo manejarías el paginado en un SP?
Con offset y limit/top/fetch, igual que una consulta normal
Algo que pudiera agregar es, que falsamente estamos creyendo que no debemos topar la BD esto por el uso de los ORM (Moda) el motor de su forma nativa funcionará mejor con lo suyo, por eso los ERP's de largo siguen usando SP, cierto es que los ORM han mejorado mucho en su funcionamiento, pero, la forma en que funciona un motor de BD es que al hacer una consulta, la analiza y en ese momento la "compila" esto en transacciones emprersariales es costo de servidor, mientras que un SP se precompila (Ya conoce y sabe lo que debe hacer, por eso simplemente la ejecuta, en lugar de analizar un query ver que trae y luego de eso ejecutar). Donde la lógica es compleja, conviene de largo usar los SP, mientras que en un simple crud, si nos sirve mucho los ORM.
Hola, muy bueno el video. ¿Cuál sería el mejor enfoque para mantener la creación de los SP dentro de las migraciones? Porque de esta forma no se generará automáticamente esos procesos/funciones al momento de inicializar la aplicación.
en mi experiencia, proyecto separado para administrar los SP, ten en cuenta que los SPs también hay que testearlos.
@@NetMentor Gracias por la respuesta!!! Mi duda radicaba más que nada en el versionado de las migraciones y en la facilidad para el despliegue. He probado de crear una migración sin ningun cambio en el modelo, de forma tal que el "up" y el "down" queden vacíos y luego completarle el código de los SP con la ejecución del CREATE PROCEDURE y el DROP PROCEDURE a mano. Es algo que funciona pero no del todo prolijo. Pensé que tal vez estaba resuelto de alguna forma por el Framework. Muchas gracias!
para store procedures que opinas de dapper?
que esta bien, al final te permite mapear el resultado del SP a un objeto igual que si fuera una consulta normal.
Es la mejor forma si estas en Framework Core
El tema de los StoreProcedures es muy polémico, hay quienes de plano los ignoran y "satanizan" su uso sobre todo en comunidades de Java dejando la base de datos como mero contenedor de tablas desperdiciando el potencial de las funciones y, justo los SProcedures, en lo personal yo prefiero el extremo opuesto, delegar la mayor parte de la lógica de negocio al Sistema Gestor de Bases de datos y hacer llamadas a los SPs desde el código.
El mayor problema de dejar lógica en los SPs es que muy comunmente se ignoran los tests de los propios procedures, asi que a la larga "cuesta" mas querer hacer un cambio. Yo personalmente prefiero tener la lógica en código, pero hay situaciones donde es mucho mejor tenerla en SQL.
@@NetMentoren el caso de que se maneje sp como se podrian hacer los test ya que es un poco complicado el tema
En sql se pueden hacer tests con t-sql o el equivalente de la BBDD que estés utilizando.