LINQ

Ni lo he mirado... Ha sido una búsqueda por google, la url es
http://www.123aspx.com/redir.aspx?res1351, y creo que es un artículo
de la MSDN...

Tella sí que puso una vez en sus foros un código ofuscado en C#... a
ver si lo tiene y lo pongo aquí.

on 07/12/2007, Octavio Hernandez supposed :

Rafa,

No me dirás que ese código es de un programa de verdad...
Eso se podría simplificar mucho:

a) quitando ese this que has puesto por doquier y que no hace ninguna falta
b) poniendo nombres "decentes" a a, p, q y r.
c) esa fórmula que parece que calcula el resto de la división por 50 se puede
hacer más sencilla...

Slds - Octavio


"RFOG" wrote in message
news:

Pues no es tan difícil leer C++, joer. :-P

Esto es C#:

public void c() {
if (this.p > 0) {
this.p = this.p - 1;
if (this.r.Length >= 2)
this.r = this.r.Substring(0, this.r.Length - 2);
this.a(this.q[this.p - this.p / 50 * 50]);
this.a(this.e);
}
}

Así que ojo con la viga en el ojo propio.

:-P

http://www.123aspx.com/redir.aspx?res1351

Hala.

Octavio Hernandez wrote on 06/12/2007 :

Ja, ja, muy bueno eso, Carlos!

Saludos - Octavio


"Carlos M. Calvelo" wrote in message
news:
Hola Octavio,

On 6 dec, 10:46, "Octavio Hernandez"
wrote:

Hola, Alfredo!

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.

Como dice RFOG: [MODO CACHONDEO ON]

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++.

:-)

Saludos,
Carlos

==>> 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
>> Si haces creer a la gente que están pensando, te adorarán; pero si las
haces pensar, te odiarán visceralmente.

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
Si haces creer a la gente que están pensando, te adorarán; pero si las
haces pensar, te odiarán visceralmente.

propio ejecutable.

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

Si pero en las aplicaciones siempre es normal tener algun que otro
formulario con un grupete de condiciones de seleccion para el cual la unica
forma practica de armarlas es en una cadena generada en la aplicacion,
porque tenerlas en un store procedure pre-programadas puede ser menos
practico y mas dificil de modificar.
Y para esto creo que tambien Linq viene a traer mas rigidez que
flexibilidad.

Alberto

Hola:

Aque te refieres con un cursor local manejable?

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.

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.

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

Saludos.

"Pablo Roca" escribió en el mensaje de
noticias news:

"Berto" <bb> escribió en el mensaje
news:

Esa es una gran verdad sobre todo los que trabajamos en pequenas empresas
donde tratar de reducir los costos de desarrollo es un factor
predominante.

Exacto. La cantidad de dinero y tiempo que uno invierte en código como
para que nos pille la ola de MS del vamos a "mejorar" esto.

Por lo menos el Linq to sql claro que si. En Foxpro uno envia una
consulta al servidor y sin mucho rollo obtienes el llamado cursorset que
no es mas que una clase bien tipada sin ningun overhead.
Sera hacia alla que va el Linq to sql? ojala.

A ver ... pero con Linq to SQL tendremos un recorset que a su vez sea
consultable por sql? Es decir un autentico cursor local manejable? ...
investigaremos ...


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Hola, Berto!

Encapsular esas condiciones en una función booleana que luego se utiliza en
la
cláusula where de la consulta me parece una manera muy práctica...

En cualquier caso, LINQ to SQL tiene un método ExecuteQuery<T>() al
que puedes pasarle la sentencia SQL.

Slds - Octavio


"Berto" <bb> wrote in message
news:%23%

propio ejecutable.

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

Si pero en las aplicaciones siempre es normal tener algun que otro
formulario con un grupete de condiciones de seleccion para el cual la
unica forma practica de armarlas es en una cadena generada en la
aplicacion, porque tenerlas en un store procedure pre-programadas puede
ser menos practico y mas dificil de modificar.
Y para esto creo que tambien Linq viene a traer mas rigidez que
flexibilidad.

Alberto

Encapsular esas condiciones en una función booleana que luego se utiliza
en la
cláusula where de la consulta me parece una manera muy práctica...

Si fuese con condiciones pocas y sencillas quizas, pero de no ser asi, algo
comun en los forms de consultas, no creo.

Yo digo de cuando en un form de usuario uno tiene varios criterios de
seleccion que el usuario puede elegirlos arbitrariamente. ejemplo un
criterio es un rango de fechas, otro critero es marcar varias claves
foraneas contenidas, otro es indicar el valor de un campo estatus, otro es
indicar una porcion de texto para un campo nombre, etc. etc. pero cada
criterio el usuario puede o no usarlos (opcionalmente).
Para que sea eficiente si uno lo define en un store procedure tiene
necesariamente que enumerar las posiblidades de where para que se guarden
los planes de ejecucion; y no solo where sino tambien los joins y hasta
subconsultas que pudiesen estar involucradas. Es algo engorroso que se
multiplica mientras mas criterios de busqueda tenga el form. A veces uno
llega al extremo de generalizarlo en una especie de Wizard que el usuario
genera como quiera. Por otro lado, ponerlo en una funcion orientada a
registros como dices es todavia peor puesto que no se aprovecharian
directamente los planes de ejecucion de la sentencia select como un todo
(con todos sus joins).
La otra manera es armar la cadena dinamica en el propio servidor pero ahi la
ventaja a armarla desde la aplicacion no la veo en absoluto.

En cualquier caso, LINQ to SQL tiene un método ExecuteQuery<T>() al
que puedes pasarle la sentencia SQL.

Cierto, eso lo estoy viendo pues para los fines servirá igual o parecido a
como se usa en la version anterior.


Saludos


Alberto