Bueno, aca para los capos de c# tengo un par de consultas


Hasta ahora en mi laburo use 3 formas para acceder a las DB

- stored procedures + dataset
- Tableadapters
- Linq

(no conozco tanto de c# para saber si hay mas combos locos)

Lo que mas use, igual, fue stored procedures + ds

Los tableAdapters toque un par de veces, y linq lo toque de costado, modificando un par de consultas ya hechas


Ahora bien, cual les parece mejor para utilizar en sus sistemas ?


Aca voy con la experiencia de cada uno, ya sea por
- Cantidad de Codigo escrito
- Facilidad de codeo/uso
- Reusabilidad de consultas/Datasets
- Uso de otras tecnologias (ej stored requiere usar SQL)
- Performance (he oido que linq es mas lento, pero es tipo.. radiopasillo[?])


Alguno ha utilizado combinaciones de estas ?
Cual es mas performante para apps web ? y para apps de escritorio ?

Por mi parte, linq me parecio muy groso al ppio pero ahora no me parece tan copado (?) ademas de que se me hace engorroso.
Sobre los TableAdapter debo decir que son muy grosos.
usar Stored da mucha comodidad, pero ante varias db se hace complicado el mantenimiento, ademas de que llevas algo de logica fuera del codigo
Algunos tips para cada uno de estos tipos ?


Por supuestos si hay formas similares de otras tecnologias, echen luz sobre el tema

Pregunto y respondo desde un punto de vista totalmente ignorante:

¿LinQ no te daría la ventaja de poder hacer refactors más facilmente que tirando las querys?

Es una de las ventajas


de hecho, CREO que el VisualStudio te trae un par de herramientas que te refactorizan automaticamente consultas de linq (en vez de hacerlo a manopla)

En java al menos, ese es motivo suficiente por el cual conviene más usar Criteria (un linq pero mas objetoso y menos copado) que HSQL

Yo tengo "experiencia" usando Stores + Dataset y LINQ.

Personalmente comparando los dos, linq es mejor porque permite usar stores muy fácil (lo tiras en el dbml y te genera solo el método con los parámetros de entrada y la clase de salida, si son necesarios) y te permite hacer queries simples sin necesidad de armar un store entero.

Aún así puede traer (en experiencia propia) un poco de mareo a la hora de saber que está haciendo cada cosa, porque al tener la mitad del código con stores y la mitad con queries de linq de vuelve un problemita de mantener.

En temas de velocidad, usando un perfilador, yo no noté diferencias, el código que genera linq está bien optimizado y normalmente funciona bien. No se que tul haciendo alguna consulta muy complicada. El problema que si trae es que le pega doscientas veces a la base y es más jodido de debuggear (con el store estás un toque más organizado).

Que se yo, como todo depende de lo que estés haciendo, igual LINQ no es solo tirar consultas, los métodos que provee para manejar Listas y Xml con lamba son alegría.

(27-02-2012 20:45)Nicosunshine escribió:  En temas de velocidad, usando un perfilador, yo no noté diferencias, el código que genera linq está bien optimizado y normalmente funciona bien. No se que tul haciendo alguna consulta muy complicada. El problema que si trae es que le pega doscientas veces a la base y es más jodido de debuggear (con el store estás un toque más organizado).

Le pega, o "si le pega" ? ahi no entendi. No se tanto del funcionamiento interno de linq como para saber cuantas veces accede a la db
Ahi no tendria perdida de performance ? siendo que entro mas veces a la db que un llamado a un stored

(27-02-2012 20:45)Nicosunshine escribió:  Que se yo, como todo depende de lo que estés haciendo, igual LINQ no es solo tirar consultas, los métodos que provee para manejar Listas y Xml con lamba son alegría.

claro, igual apuntaba especificamente a la consulta de db. Pero si se puede usar con lambdas (te morfaste la d ) y xml, y si, son alegria

(27-02-2012 20:49)gonnza escribió:  Le pega, o "si le pega" ? ahi no entendi. No se tanto del funcionamiento interno de linq como para saber cuantas veces accede a la db
Ahi no tendria perdida de performance ? siendo que entro mas veces a la db que un llamado a un stored

Depende del caso, pero por ejemplo para hacer un Select * normalmente se transforma en un Select por cada campo que necesita, y como la conexión no se cierra, no es más lento.

(las lamba se la re bancan)

La posta es SP.

Cuando te das cuenta que un error en PROD seria facilmente solucionable si esa puta query estaria en la DB, te queres matar.

La verdad que no use Linq todavia, pero me gusta mas tener los stores en la base bien diseñados, sin muchas lineas.

(27-02-2012 22:38)ebric escribió:  La posta es SP.

Cuando te das cuenta que un error en PROD seria facilmente solucionable si esa puta query estaria en la DB, te queres matar.

algun ejemplo ?

(27-02-2012 23:00)shadow_mx escribió:  La verdad que no use Linq todavia, pero me gusta mas tener los stores en la base bien diseñados, sin muchas lineas.

claro, a mi tambien, el tema se vuelve cuando usas un sistema en 100 bases, a veces el mantenimiento se vuelve un poco heavy (me pasa en el laburo)

La posta es no usar ninguno de los dos. NHibernate (en alguna de sus variantes) FTW. Si necesitas ultraperformance, ahi podemos charlarlo y buscar otra cosa, pero para el 99% de las aplicaciones del mercado, va como piña. La posta es pensar en objetos y que alguien (Hibernate) se encargue de persistir eso.

Si chicos, es posible... no es un versito de la gente de paradigmas o TADP

(posta, no lo digo en joda )

Si vos tenes un objeto usuario... la posta es que el usuario tenga sus atributos y su metodos (loguearse, modificarse, crearse, etc) dentro de si mismo. Y quien persiste toda esa info? Hibernate. Vos simplemente creas el objeto y lo agregas a los que conoce Hibernate. Despues se los pedis a Hibernate. Si lo modificas, no tenes que decirle "guardalo". Es logico que lo va a hacer porque para eso modificaste el original.

La onda es asi, mapeas un objeto contra una tabla, y a su vez cada atributo del objeto contra una columna de la tabla. Si respetas las convenciones, lo hace solo. Y voalá (como diria Nanu), anda todo. Tenes una forma de mapear las relaciones 1-1, 1-N y N-N, formas de mapear herencias, etc. La onda es que vos pienses en objetos y relaciones entre ellos, y el framework hace el laburo por atras para que eso se persista.

Si a alguno le interesa nos robamos un aula de medrano algun finde y charlamos un par de estas cosas

es simple: sp si la performance es critica, LINQ si queres que sea mas mantenible y OOP.

Si me preguntas a mi: con un equipo de desarrollo grande , te conviene sp. Cambiar algo no implica que tengas que tocar el build , solo modificar el server con la BD (y si haces las cosas bien, la DB no esta con el build). Ademas que cuando explote algo , vas a tener la ayuda de los DBAs , si es con Linq/Hibernate olvidate que te entendiendan.

Ademas los recursos humanos que saben usar SQL pelado sobran. Los que saben Hibernate/Linq? son la minoria.

Yo la verdad que tuve problemas con Hibernate, con objetos pesados y muchas acciones. Un proceso que para 2000 acciones se hacia en segundos, cuando las acciones superaban las 40 mil, el proceso tardaba mas 5 horas. Al final nunca lo pude resolver y saber con bien porque tardaba tanto. Era una combinacion entre Hibernate, las transacciones y los triggers de las tablas.... Era todo muy raro lo que pasaba.


PD: Igual me gustaria saber como se arman esas clases de hibernate en forma casi automatica, Mayormente use las DALS y me gustas xD.