none
Cuales son las mejores practicas para usar stores procedures en entity framework RRS feed

  • Pregunta

  • Hola a todos,

    Tengo una duda, me gustaría saber cuales son las mejores practicas para usar stored procedures en Entity Framework.

    Muchas gracias por todos sus aportes.

    sábado, 7 de enero de 2017 16:31

Respuestas

  • Estimado Geovanny,

    Descuida, no veo discrepancia, tras leer ambos aportes noto que apuntamos a lo mismo: no tiene mayor sentido utilizar únicamente procedimientos almacenados si se decide por el marco de trabajo de Entity Framework, sin embargo habrán situaciones en que sea necesario su uso (me refiero a cualquier mecanismo del que se pueda obtener datos: procedimientos almacenados, vistas, etc.); es lo que entendí de tu aporte y es lo mismo que yo menciono en el mio.

    Sin embargo, la parte que tomas textualmente creo que no fue correctamente entendida o fui yo el que no supo redactarlo de manera correcta, básicamente me refería a que no se puede culpar la "carencia" de rendimiento a Linq o EF (según quieras verlo) cuando no se ha tenido el cuidado y el conocimiento/experiencia para escribir una consulta en Linq (no sólo me refiero a sintaxis), sucederá lo mismo escribiendo consultas en t-sql, en cualquier lenguaje de programación, o en cualquier otra circunstancia, no es exclusivo de Linq; muchas veces es fácil culpar al contexto o la tecnología y no caer en que probablemente la raíz del problema es nuestro ligero conocimiento o experiencia. Pues bien -y esto también lo dije-, ante algún caso donde sea mejor hacer uso de un procedimiento almacenado pues habrá que echar mano de el, en tanto no lo permita EF (por restricción o por rendimiento)

    Pdta.- No hay que temer a las polémicas, de los puntos de vista distintos es que se aprenden lecciones.


    sábado, 7 de enero de 2017 21:23

Todas las respuestas

  • En mi experiencia ambos mundos (EF y SP en SQL Server) los he usado de manera complementaria, de hecho mantengo una posición critica y hasta cautelosa acerca del uso de ORM y la calidad de las consultas y el impacto de Performance en SQL Server.

    De hecho el uso de SP con EF hasta donde se no es muy extendido, al respecto te recomendaria que revisaras el blog de  la autora Julie Lerman, y bueno, te puedo decir que por lo general cuando combinas ORM con SP en general las consultas basadas en Linq to Entities ocupan un % de consultas triviales y que debes procurar de bajo impacto, y los SP's cuando requieres un control sobre el Performance y la lógica de negocios mas alla de simples SELECT.

    Unos links de <g class="gr_ gr_31 gr-alert gr_spell gr_run_anim ContextualSpelling ins-del multiReplace" data-gr-id="31" id="31">interes</g>:

    http://www.c-sharpcorner.com/UploadFile/ff2f08/call-store-procedure-from-entity-framework/

    http://thedatafarm.com/blog/


    "Oh, the wind, the wind is <g class="gr_ gr_51 gr-alert gr_gramm gr_run_anim Style replaceWithoutSep" data-gr-id="51" id="51">blowing,through</g> the <g class="gr_ gr_49 gr-alert gr_gramm gr_run_anim Punctuation only-ins replaceWithoutSep" data-gr-id="49" id="49">graves</g> the wind is <g class="gr_ gr_52 gr-alert gr_gramm gr_run_anim Style replaceWithoutSep" data-gr-id="52" id="52">blowing,Freedom</g> soon will come; then well come from the shadows".The Partisan(Leonard Cohen) Email: me[at]geohernandez.net Blog:www.geohernandez.net


    sábado, 7 de enero de 2017 17:17
  • Axom Omar,

    Las buenas practicas que debes considerar al escribir código t-sql son independientes a la tecnología que los invocará, ya sea ADO .Net, Entity Framework o cualquier otro ORM. Sin embargo, ¿por qué quisieras utilizar procedimientos almacenados cuando decidiste utilizar un ORM? Una de las ventajas de EF es el poder escribir consultas (mediante Linq To Entities) contra un modelo conceptual, ¿qué la calidad de consultas se ve penalizada?, pues vamos, si no sabes escribir consultas en Linq no esperes que la resultante sea óptima o eficiente, es tanto como esperar rendimiento escribiendo malas consultas en t-sql. 

    Sin embargo, si que es posible utilizar procedimientos almacenados en un contexto de Entity Framework, pero su uso se debería resumir a casos muy estrictos donde la complejidad o "rendimiento" no pueda ser cubierto por EF, si estás pensado utilizar únicamente procedimientos almacenados con Entity Framework  será mejor que te bajes del bus de EF y vuelvas a subir al de ADO .Net.


    Espero que la información proporcionada te haya sido de utilidad, quedo atento a tus comentarios.
    sábado, 7 de enero de 2017 18:17
  • Me gustaría añadir un poco mas al tema, porque entiendo que en muchas ocasiones los escenarios obligan a conjugar diferentes factores y tecnologías.  Me permito discrepar con William (sin animo de polemizar) en esta afirmación: "pues vamos, si no sabes escribir consultas en LINQ no esperes que la resultante sea óptima o eficiente"; existen escenarios y situaciones en la que incluso una consulta LINQ escrita por Jon Skeet o cualquier gurú del tema te pueden provocar resultados con un coste muy alto a nivel de rendimiento, evidentemente si eres hábil con LINQ esto puede disminuir el numero de escenarios donde tu consulta genere pésimos resultados, pero no estarás exento de fallas.

    Otro punto que creo de interes es el hecho de que ambas tecnologias (ORM) y los procedimientos almacenados pueden convivir dentro del ecosistema de tu app, de hecho yo trabaje en mi ultima empresa en una solución que usaba DDD y a nivel de la capa de repositorio contabamos con una serie de "frameworks" para la interacción con ADO .NET y luego se agrego el usuo de Entity Framework (Code First), por lo que ambas no son excluyentes, lo que si no hace mucho sentido es que uses un ORM solo para interactuar con SP, ya que no tienes ninguna ventaja adicional al respecto.

    Para finalizar, hace un tiempo atras intercambie correos con Kevin Boles quien brindo un interesante workshop sobre el tema en la empresa de un colega, el tema iba precisamente de esto y se titulaba: Know what your code is doing !!!, por tema de copyright no tengo autorización para subirlo a un repositorio, pero si me escribes a mi correo te lo puedo enviar, es muy interesante y hay ejemplos practicos del tema.

    Enlaces de Interes(en ingles):

    https://www.simple-talk.com/dotnet/.net-tools/entity-framework-performance-and-what-you-can-do-about-it/

    https://github.com/bcemmett/EntityFrameworkSchoolSystem

    http://blog.waynesheffield.com/wayne/archive/2012/06/orm-tools/


    "Oh, the wind, the wind is blowing,through the graves the wind is blowing,Freedom soon will come; then well come from the shadows".The Partisan(Leonard Cohen) Email: me[at]geohernandez.net Blog:www.geohernandez.net

    sábado, 7 de enero de 2017 20:27
  • Estimado Geovanny,

    Descuida, no veo discrepancia, tras leer ambos aportes noto que apuntamos a lo mismo: no tiene mayor sentido utilizar únicamente procedimientos almacenados si se decide por el marco de trabajo de Entity Framework, sin embargo habrán situaciones en que sea necesario su uso (me refiero a cualquier mecanismo del que se pueda obtener datos: procedimientos almacenados, vistas, etc.); es lo que entendí de tu aporte y es lo mismo que yo menciono en el mio.

    Sin embargo, la parte que tomas textualmente creo que no fue correctamente entendida o fui yo el que no supo redactarlo de manera correcta, básicamente me refería a que no se puede culpar la "carencia" de rendimiento a Linq o EF (según quieras verlo) cuando no se ha tenido el cuidado y el conocimiento/experiencia para escribir una consulta en Linq (no sólo me refiero a sintaxis), sucederá lo mismo escribiendo consultas en t-sql, en cualquier lenguaje de programación, o en cualquier otra circunstancia, no es exclusivo de Linq; muchas veces es fácil culpar al contexto o la tecnología y no caer en que probablemente la raíz del problema es nuestro ligero conocimiento o experiencia. Pues bien -y esto también lo dije-, ante algún caso donde sea mejor hacer uso de un procedimiento almacenado pues habrá que echar mano de el, en tanto no lo permita EF (por restricción o por rendimiento)

    Pdta.- No hay que temer a las polémicas, de los puntos de vista distintos es que se aprenden lecciones.


    sábado, 7 de enero de 2017 21:23
  • En hora buena por la aclaración y el hecho de haber complementado tu comentario Willams, de hecho no tengo ninguna reserva o temor a dar mi opinión sobre cualquier tema, sin embargo a partir de la incorporacion de ORM dentro del mundo del desarrollo se han vertido rios de tinta (y de caracteres :-) ) sobre los que no me interesa redundar y prefiero analizar y contextualizar situaciones especificas, creo que seria de mayor provecho, y dicho lo anterior me gustaria saber si el usuario que ha creado este hilo ha tenido tiempo de leer nuestros comentarios y si tiene algo más que agregar.

    "Oh, the wind, the wind is blowing,through the graves the wind is blowing,Freedom soon will come; then well come from the shadows".The Partisan(Leonard Cohen) Email: me[at]geohernandez.net Blog:www.geohernandez.net

    domingo, 8 de enero de 2017 19:20