LINQ

Hola:

Aque te refieres con un cursor local manejable?

seguro que Pablo se refiere a un cursor de VFP que uno lo llena con datos
desde SQL server pero luego puede usar ese conjunto en la aplicacion
localmente para aplicarle nuevas consultas y hasta generar otros cursores
locales en la aplicacion, modificarlos, borrarlos, etc.,

LINQ hoy por hoy no es mas que la traducción de un lenguaje net a sql
dinamico con parametros que se ejecuta con el procedimiento
sp_execute_sql.

Pero eso lo hacen todos los lenguajes cuando hay parametros en una consulta
que se manda al servidor.

Es decir se puede hacer de todo pero todo es sql dinamico, parece ser que
ahora que han inventado el LINQ el sql dinamico ya no es tan malo.

Creo que el sql dinamico cuando es parametrizado, no tiene problemas de
inyeccion de codigo.

Yo me quedo con los procedimientos almacenados, aunque alguno de ellos no
tenga mas remedio que utilizar sql dinamico en el servidor.

Pero siempre habra algun caso donde haya que armar un query desde la
aplicacion en una cadena de texto y mandarla tal cual al servidor, ya que no
todo estara 100% previsto en una aplicacion para tenerlo todo en store
procedures.

Saludos

Alberto

Hola Octavio,

On Thu, 6 Dec 2007 10:46:28 +0100, "Octavio Hernandez"
wrote:

La verdad es que a mí el SQL incrustado nunca me gustó. Alguien que leyera
un código fuente con SQL incrustado... pues eso, que estaba leyendo C++
"salpicado" con trozos de SQL.

Pues a mi LINQ me parece casi lo mismo, solo que con una sintaxis peor
en muchos casos.

Resolvía el mismo problema: cargar resultados de consultas en
colecciones sin tener que poner código SQL entre comillas y
verificando la sintaxis en tiempo de compilación.

LINQ es algo verdaderamente *integrado* en el lenguaje. Y para mí lo más
importante es que puede ser usado para consultar casi cualquier cosa, y no
únicamente SGBD. O sea, es un verdadero recurso de propósito general.

http://geeks.ms/blogs/ohernandez/ar...o-sql.aspx

Ya lo había visto y no estoy nada de acuerdo en que solo sea "azucar
sintáctico".

Además para hacer consultas sobre archivos XML tienes operadores
especiales, por lo que puedes consultar casi cualquier cosa pero de
formas distintas, con lo que ya no es tanta maravilla.

La utilidad de consultar archivos XML creo que es muy pequeña, y LINQ
to Objects está implementado de una forma tan ingenua que sirve para
poco por lo lento que es. Y creo que no lo van a tener nada fácil para
optimizarlo.

Aunque si que creo que cosas como LINQ to Amazon podrían no estar mal
del todo sobre todo cuando las comparamos con Web Services.

He estado leyendo tu excelente libro sobre LINQ estos días y me ha
parecido entender que LINQ to SQL necesita que se generen clases para
corresponder a cada tabla. ¿Es eso así?

Si es cierto entonces menudo desastre.


Saludos
Alfredo

Hola RFOG,

On Thu, 06 Dec 2007 11:14:32 +0100, RFOG
wrote:

IMHO (que no entiendo de bases de datos), sería un principio de agujero
de seguridad bastante grave. Tan sólo habría que mirar con un editor
binario dichas cadenas... ¡y a jugar! Y luego las sustituyes en el
propio ejecutable.

Esto no es ningún problema si el DBA ha hecho bien su trabajo.
Deberías de poder distribuir el código fuente de las aplicaciones sin
tener por que preocuparte.

Además el SQL incrustado podría ser traducido por el compilador a
alguna especie de cófigo intermedio y así no ser visto tan fácilmente.

Si se escribie código SQL como cadenas de caracteres como hace casi
todo el mundo entonces si que es más difícil de ocultar.

SI no me equivoco LINQ termina siendo código compilado... Algo más
difícil de sacar.

Prácticamente igual de fácil con algo como Reflector.

Bah, bah, LINQ no es más que los bloques de código de Clipper con otro
nombre.

De Clipper no, de un pseudoSQL con 4 chorradas más.


Saludos
Alfredo

Hola Carlos,

On Thu, 6 Dec 2007 05:13:39 -0800 (PST), "Carlos M. Calvelo"
wrote:

La verdad es que a mí el C++ incrustado nunca me gustó. Alguien que
leyera
un código fuente con C++ incrustado... pues eso, que estaba leyendo
SQL
"salpicado" con trozos de C++.

Pues es cierto, a mi tampoco :-)

Eso de tener que meter los resultados de las consultas en "arrays" en
lugar de manejarlos directamente :-(


Saludos
Alfredo

Holas...

"Alfredo Novoa" escribió en el mensaje de noticias
news:

Hola RFOG,

On Thu, 06 Dec 2007 11:14:32 +0100, RFOG
wrote:

IMHO (que no entiendo de bases de datos), sería un principio de agujero
de seguridad bastante grave. Tan sólo habría que mirar con un editor
binario dichas cadenas... ¡y a jugar! Y luego las sustituyes en el
propio ejecutable.

Esto no es ningún problema si el DBA ha hecho bien su trabajo.
Deberías de poder distribuir el código fuente de las aplicaciones sin
tener por que preocuparte.

Claramente no es mi área de especialización, pero entiendo perfectamente lo
que comentas por comparación con otras cosas de las que sí que creo que
entiendo.

Además el SQL incrustado podría ser traducido por el compilador a
alguna especie de cófigo intermedio y así no ser visto tan fácilmente.

¿Alguno lo hace?

Si se escribie código SQL como cadenas de caracteres como hace casi
todo el mundo entonces si que es más difícil de ocultar.

SI no me equivoco LINQ termina siendo código compilado... Algo más
difícil de sacar.

Prácticamente igual de fácil con algo como Reflector.

Vale, pero esa es una de las "pifias" del .NET y en general de todas las
herramientas/lenguajes que usen bytecode, aunque con C++/CLI la ingeniería
inversa está más complicada si es una aplicación mixta.

Bah, bah, LINQ no es más que los bloques de código de Clipper con otro
nombre.

De Clipper no, de un pseudoSQL con 4 chorradas más.

Hombre, yo lo decía en plan cachondeo, de lo que yo conozco el Clipper fue
el primero que dejó guardar trozos de programa dentro de una tabla y luego
poder ejecutarlos, o meter eso mismo en una variable y ejecutarla, aunque el
DBASE también permitía algo de eso pero menos potente...

Saludos
Alfredo

Microsoft Visual C++ MVP
==Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación
El amor es ciego.