LINQ ?

11/04/2008 - 13:06 por Michelle | Informe spam
No he siquiera mirado para LinQ pero antes de mirarlo quien pueda me de su
opinion de que tal funciona para trabajar con datos y si es mejor que usar
la forma tradicional (datatables) ?

Preguntas similare

Leer las respuestas

#1 Alberto Poblacion
11/04/2008 - 18:56 | Informe spam
"Michelle" wrote in message
news:
No he siquiera mirado para LinQ pero antes de mirarlo quien pueda me de su
opinion de que tal funciona para trabajar con datos y si es mejor que usar
la forma tradicional (datatables) ?



Bueno, depende de lo que entiendas por ser "mejor". Por ejemplo, escribiendo
las sentencias SQL por el método tradicional puedes en algunos casos
escribir sentencias más "optimizadas" que las que LINQ generaría
automáticamente, por lo que desde este punto de vista (optimización del Sql
enviado al servidor) sería mejor operar por el método tradicional. Pero por
otra parte, esas sentencias escritas a mano son strings desde el punto de
vista del compilador, por lo que no tienes ayuda del intellisense al
escribirlas y no detectas los errores hasta el momento de la ejecución. Por
el contrario, LINQ está integrado en el lenguaje, y los errores de sintaxis
se detectan en tiempo de compilación, por lo que desde este punto de vista
sería "mejor" usar LINQ. Y seguro que, de la misma manera, podemos encontrar
múltiples argumentos adicionales tanto a favor como en contra de cada una de
las dos opciones.
Respuesta Responder a este mensaje
#2 Pablo Roca
11/04/2008 - 20:58 | Informe spam
Buena respuesta Alberto,

Me esperaba una defensa del LINQ olvidandose del tema de las sentencias
"optimizadas" por LINQ :)

LINQ, lo veo interesante, pero como dices bien, depende. LINQ to Objects
fantástico, LINQ to SQL mmm habrá que ver como se optimizan esas sentencias,
pero la "magia SQL" prefiero hacerla yo en el servidor con procedimientos
almacenados u objetos de negocio con consultas parametrizadas

LINQ to Entities, pues vamos a esperar a que salga y habrá que echarle un
ojo, tiene mejor pinta que LINQ to SQL


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
#3 Alfredo Novoa
12/04/2008 - 08:29 | Informe spam
Hola Alberto,

On Fri, 11 Apr 2008 18:56:54 +0200, "Alberto Poblacion"
wrote:

Bueno, depende de lo que entiendas por ser "mejor". Por ejemplo, escribiendo
las sentencias SQL por el método tradicional puedes en algunos casos
escribir sentencias más "optimizadas" que las que LINQ generaría
automáticamente,



Pero la sintaxis de LINQ es muy parecida a SQL y la traducción que
hace es muy directa, así que también puedes "optimizar" las sentencias
LINQ para que generen secuencias SQL más "óptimas".

Al final el que tiene que optimizar de verdad es el optimizador del
SGBD, si este funciona bien debería dar más o menos igual como
escribamos la sentencia.

Y seguro que, de la misma manera, podemos encontrar
múltiples argumentos adicionales tanto a favor como en contra de cada una de
las dos opciones.



Pero yo pienso que los argumentos en contra tienden a ser más flojos
:-)

Para mi el fallo más garrafal del LINQ (además de la sintaxis
espantosa) es que si quieres hacer un update tienes que volver al SQL
de siempre :-(


Saludos
Alfredo
Respuesta Responder a este mensaje
#4 Michelle
12/04/2008 - 22:44 | Informe spam
De esa respuesta yo deduzco que es mas conveniente todavia el metodo
tradicional.


"Alberto Poblacion"
escribió en el mensaje news:eTX5aU$
"Michelle" wrote in message
news:
No he siquiera mirado para LinQ pero antes de mirarlo quien pueda me de
su
opinion de que tal funciona para trabajar con datos y si es mejor que
usar
la forma tradicional (datatables) ?



Bueno, depende de lo que entiendas por ser "mejor". Por ejemplo,
escribiendo las sentencias SQL por el método tradicional puedes en algunos
casos escribir sentencias más "optimizadas" que las que LINQ generaría
automáticamente, por lo que desde este punto de vista (optimización del
Sql enviado al servidor) sería mejor operar por el método tradicional.
Pero por otra parte, esas sentencias escritas a mano son strings desde el
punto de vista del compilador, por lo que no tienes ayuda del intellisense
al escribirlas y no detectas los errores hasta el momento de la ejecución.
Por el contrario, LINQ está integrado en el lenguaje, y los errores de
sintaxis se detectan en tiempo de compilación, por lo que desde este punto
de vista sería "mejor" usar LINQ. Y seguro que, de la misma manera,
podemos encontrar múltiples argumentos adicionales tanto a favor como en
contra de cada una de las dos opciones.


Respuesta Responder a este mensaje
#5 Jesús López
14/04/2008 - 15:33 | Informe spam
El problema Alfredo es que muchas veces no da igual como escribas la
sentencia SQL. En ciertos casos puedes obtener un aumento de rendimiento
espectacular escribiéndolas de otra forma. Si usas LINQ to SQL o Entity
Framework, pierdes el control de las sentencias SQL que se envían al
servidor. Al perder tal control, también pierdes capacidad de optimización.

Yo estoy convencido de que si el rendimiento es un factor crítico en tu
aplicación, entonces no es buena idea usar LINQ to SQL ni Entity Framework.

Si en vez de usar LINQ to SQL o Entity Framework, o sentencias SQL
incrustadas en el código de la aplicación cliente, se usan procedimientos
almacenados, entonces tu aplicación es aún más optimizable, ya que un DBA
puede optimizar aún más la aplicación incluso estando ya en producción, dado
que el DBA puede cambiar el código de los procedimientos almacenados.


Con LINQ to SQL o Entity Framework o cualquier otra herramienta que genere
SQL en tiempo de ejecución, tienes menos posibilidades de optimización
incluso en la fase de desarrollo, ya te tienes que aguantar con el código
SQL que generan estas herramientas.

Con código SQL incrustado en la aplicación cliente, puedes optimizarlo en
tiempo de desarrollo. Pero las condiciones cambian mucho en producción,
incluso la misma aplicación instalada en distintos clientes. Y se necesita
poder optimizar la aplicación ya en producción. Si usas procedimientos
almacenados entonces esto se puede hacer, si no, es mucho más difícil
hacerlo.

Saludos:

Jesús López
www.solidq.com


"Alfredo Novoa" escribió en el mensaje
news:
Hola Alberto,

On Fri, 11 Apr 2008 18:56:54 +0200, "Alberto Poblacion"
wrote:

Bueno, depende de lo que entiendas por ser "mejor". Por ejemplo,
escribiendo
las sentencias SQL por el método tradicional puedes en algunos casos
escribir sentencias más "optimizadas" que las que LINQ generaría
automáticamente,



Pero la sintaxis de LINQ es muy parecida a SQL y la traducción que
hace es muy directa, así que también puedes "optimizar" las sentencias
LINQ para que generen secuencias SQL más "óptimas".

Al final el que tiene que optimizar de verdad es el optimizador del
SGBD, si este funciona bien debería dar más o menos igual como
escribamos la sentencia.

Y seguro que, de la misma manera, podemos encontrar
múltiples argumentos adicionales tanto a favor como en contra de cada una
de
las dos opciones.



Pero yo pienso que los argumentos en contra tienden a ser más flojos
:-)

Para mi el fallo más garrafal del LINQ (además de la sintaxis
espantosa) es que si quieres hacer un update tienes que volver al SQL
de siempre :-(


Saludos
Alfredo
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente Respuesta Tengo una respuesta
Search Busqueda sugerida