Trabajar sin DataSets

02/04/2007 - 23:54 por Pedro | Informe spam
Alguien ha visto cuando uno agrega un dataset (y sus tablas) en un
formulario visualmente la cantidad de codigo que se genera internamente en
Dataset.designer.cs?
Pregunto, es necesario todo eso para trabajar con datos. Como le hago si no
quiero trabajar con dataset o por lo menos de esa manera?

Pedro

Preguntas similare

Leer las respuestas

#11 Pedro
03/04/2007 - 20:11 | Informe spam

Los datasets tipados son un ORM de esos, y los otros ORM tienen los
mismos problemas.

Puede que el codigo no sea tan innecesario pero mucho depende del tipo de
aplicacion que desarrolles, pienso que para formularios de mantenimiento
simples quiza parte de ese codigo sea superfluo.



Es superfluo para cualquier cosa.

Yo he visto tambien varias personas que desaconsejan el uso de datasets.



Y yo a muchas que desaconsejan el uso de ORM, datasets tipados
incluidos.





Para mi es como tu dices, Un Dataset tipeado implementa un ORM. Y si uno
se pone a revisar la cantidad de codigo auto-generado en
Dataset1.designer.cs la verdad que es dificil verle utilidad a tanto código.
Del ejemplo que cité (un form con una simple tablita de mantenimiento) vi
solo en el citado archivo, mas de mil líneas de código, sin contar los demas
archivos .CS que se auto-generan para otras cosas. Algunos que pueden
estar de acuerdo con eso es probable que no hayan visto por dentro esos
archivos de codigo generado. Si eso es el costo de una herramienta RAD yo
prefiero hacerlo manual ;-).
Un amigo mio dice que esa es una de las razones de la lentitud natural del
Visual Studio y de los programas ejecutables que se producen con
el,comparando con otras herramientas.
Los ORM's comerciales obviamente implementan el mismo mecanismo de
generacion de codigo extenso y no especifico.

Esperemos que la proxima version de VS que ya esta cerca traiga mejoras al
respecto porque la verdad uno se desencanta bastante.
Respuesta Responder a este mensaje
#12 Jose Camacho Vaca
04/04/2007 - 00:24 | Informe spam
Sobre lo de Crystal, la forma que tu mencionas es exactamente como yo lo hago
y la verdad yo pense que eso era hacerlo a mano. Tengo poco con C# y la
verdad se me ha hecho una pesadilla, vengo del mundo de VFP donde todo es
mucho mas facil y productivo.

La verdad eso de la velocidad de los datasets y de Crystal es un chiste mal
hecho, yo creo que mi abuelita corre mas rápido que eso. Es una verguenza
que MS ofrezca un producto de ese tipo. Y sobre los demas objetos para
menejo de datos la verdad preferí no meterme, porque vi que son en su mayoria
peores que el dataset.

De todas formas me dejaste con la duda que mencionaba, porque los dataset a
pesar de ser typados no respetan algunos de los operadores de sobrecarga, te
doy un ejemplo:
creo un dataset Recibo con los campos id_recibo (entero), fecha (datetime) e
importe (double). Lo relleno con una consulta del tipo Select id_recibo,
fecha, importe from recibos where fecha = '20070331' y al momento de hacer la
siguiente operación: lcTexto =
miDatatable.rows[0]["importe"].tostring("#,#.00")
simplemente no se puede, tengo que primero pasarle al valor a una variable
temporal double y luego a esa variable hacerle el tostring().
No entiendo porque si en el dataset se le esta diciendo que es un double
porque no tiene los mismo operadores de sobrecarga que una variable double.
Te digo que esta gente de MS, la que hace el C#, tiene mucho que aprender.
Y los de Crystal ni hablar, es una verguenza, tarda 10 segs. en aparecer un
reporte se 1 hoja en una computadora P4 con 1Gb. de RAM?
Gracias por tu ayuda y te mando un saludo.
José Camacho Vaca
Colima, MX


"Juan Diego Bueno" wrote:

On 3 abr, 17:48, Jose Camacho Vaca
wrote:
> Perdon por la intromisión, pero a que te refieres con "no hacerlo a mano" en
> el caso de Crystal.

Me refiero a que en Crystal, para poder usar datasets como fuente de
datos, éstos han de ser tipados. Es decir, si yo inserto un dataset
genérico, Crystal no se va a enterar de su existencia. Al ser así, si
tu quieres por ejemplo, hacer un informe basado en un filtrado por la
aplicación, si no quieres usar datasets, te quedaría el recurso de
crear una vista o tabla temporal de la que tirara el informe. A mi, ya
que uso el filtrado en la aplicación para un grid, me gusta que me
pueda servir también para el informe (no se si se ha entendido).

> Otra duda por favor. Yo uso mucho los datasets, por las ventajas que tu
> mencionas pero me extraña mucho que aunque sean fuertemente tipados: 1) no
> manejan todos los tipos de datos nativos de SQLServer, 2)No en todos los
> tipos tienes todos los operadores de sobrecarga. Pongo ejemplo: 1)No tienen
> el tipo money, 2)Cuando en un dataset tienes un campo tipo double y le
> quieres hacer un ToString() pero con formato no se puede, primero lo tienes
> que meter a una variable temporal que sea tipo double y luego hacerle es
> ToString() con formato.

Lo de "fuertemente tipados" es una traducción literal mía de "strongly
typed datasets" de un artículo que leí cuando comenzaba con crystal
y .net que explicaba como poder hacer que tiraran de datasets en vez
de directamente de la base de datos. Lo de fuertemente tipados viene,
si no me equivoco, por lo específicos que son. Cuando tu creas un
dataset de este tipo, el dataadapter es específico de esa tabla
(tableadapter), etc... (Yo es que no se explicar muy bien esto, pero
lee más posts que hay gente que lo explica mejor que yo)

> No conocen alguna forma de que todo eso no sea tan tardado.
> Gracias por sus sugerencias y un saludo.

Lo de la velocidad a la hora de tratar con los datos es una cuestión
de trabajar con los registros justos. Por ejemplo, si sólo voy a
trabajar con un registro, lo suyo es que el dataset sólo contenga ese
registro. Si voy a llenar un combo desde una tabla, y esta tiene más
campos de los que voy a necesitar en mi combo para el valuemember y el
displaymember, bastaría con usar una vista que sólo contuviera los dos
campos necesarios para evitar traer todos los demás, etc... De todas
maneras, yo no trabajo con grandes proyectos y quizás haya gente que
te pueda aportar mucho más al respecto.

Y si no quieres trabajar con datasets, pues recurre a datareaders para
leer datos y a commands e incluso procedimientos almacenados para
manipularlos. Las posibilidades son muchas y variadas a mi juicio.
Mira, que yo sepa en Java, sólo dispones de un objeto cursor llamado
resultset para recorrer los registros y poco más, lo cual no quiere
decir que esté mal, pero que puede que sea insuficiente para las
necesidades de un desarrollador en un momento dado.


Respuesta Responder a este mensaje
#13 Rafael
04/04/2007 - 06:18 | Informe spam
Yo conozco C# mas a nivel academico que otra cosa pero me pregunto, no
habría alguna falta de información en eso que dicen ustedes?
Es de suponerse que a estas alturas deben haber muchas aplicaciones en
produccion en el mercado que esten hechas en C#.NET o VB.NET. Me resisto a
pensar que las cosas sean tan lentas como ustedes dicen.
Sobre todo cuando en el mercado no en todas las empresas encuentra uno
equipos muy potentes para ejecutar las aplicaciones.




"Jose Camacho Vaca" escribió en
el mensaje news:
Sobre lo de Crystal, la forma que tu mencionas es exactamente como yo lo
hago
y la verdad yo pense que eso era hacerlo a mano. Tengo poco con C# y la
verdad se me ha hecho una pesadilla, vengo del mundo de VFP donde todo es
mucho mas facil y productivo.

La verdad eso de la velocidad de los datasets y de Crystal es un chiste
mal
hecho, yo creo que mi abuelita corre mas rápido que eso. Es una verguenza
que MS ofrezca un producto de ese tipo. Y sobre los demas objetos para
menejo de datos la verdad preferí no meterme, porque vi que son en su
mayoria
peores que el dataset.

De todas formas me dejaste con la duda que mencionaba, porque los dataset
a
pesar de ser typados no respetan algunos de los operadores de sobrecarga,
te
doy un ejemplo:
creo un dataset Recibo con los campos id_recibo (entero), fecha (datetime)
e
importe (double). Lo relleno con una consulta del tipo Select id_recibo,
fecha, importe from recibos where fecha = '20070331' y al momento de hacer
la
siguiente operación: lcTexto > miDatatable.rows[0]["importe"].tostring("#,#.00")
simplemente no se puede, tengo que primero pasarle al valor a una variable
temporal double y luego a esa variable hacerle el tostring().
No entiendo porque si en el dataset se le esta diciendo que es un double
porque no tiene los mismo operadores de sobrecarga que una variable
double.
Te digo que esta gente de MS, la que hace el C#, tiene mucho que aprender.
Y los de Crystal ni hablar, es una verguenza, tarda 10 segs. en aparecer
un
reporte se 1 hoja en una computadora P4 con 1Gb. de RAM?
Gracias por tu ayuda y te mando un saludo.
José Camacho Vaca
Colima, MX


"Juan Diego Bueno" wrote:

On 3 abr, 17:48, Jose Camacho Vaca
wrote:
> Perdon por la intromisión, pero a que te refieres con "no hacerlo a
> mano" en
> el caso de Crystal.

Me refiero a que en Crystal, para poder usar datasets como fuente de
datos, éstos han de ser tipados. Es decir, si yo inserto un dataset
genérico, Crystal no se va a enterar de su existencia. Al ser así, si
tu quieres por ejemplo, hacer un informe basado en un filtrado por la
aplicación, si no quieres usar datasets, te quedaría el recurso de
crear una vista o tabla temporal de la que tirara el informe. A mi, ya
que uso el filtrado en la aplicación para un grid, me gusta que me
pueda servir también para el informe (no se si se ha entendido).

> Otra duda por favor. Yo uso mucho los datasets, por las ventajas que
> tu
> mencionas pero me extraña mucho que aunque sean fuertemente tipados: 1)
> no
> manejan todos los tipos de datos nativos de SQLServer, 2)No en todos
> los
> tipos tienes todos los operadores de sobrecarga. Pongo ejemplo: 1)No
> tienen
> el tipo money, 2)Cuando en un dataset tienes un campo tipo double y le
> quieres hacer un ToString() pero con formato no se puede, primero lo
> tienes
> que meter a una variable temporal que sea tipo double y luego hacerle
> es
> ToString() con formato.

Lo de "fuertemente tipados" es una traducción literal mía de "strongly
typed datasets" de un artículo que leí cuando comenzaba con crystal
y .net que explicaba como poder hacer que tiraran de datasets en vez
de directamente de la base de datos. Lo de fuertemente tipados viene,
si no me equivoco, por lo específicos que son. Cuando tu creas un
dataset de este tipo, el dataadapter es específico de esa tabla
(tableadapter), etc... (Yo es que no se explicar muy bien esto, pero
lee más posts que hay gente que lo explica mejor que yo)

> No conocen alguna forma de que todo eso no sea tan tardado.
> Gracias por sus sugerencias y un saludo.

Lo de la velocidad a la hora de tratar con los datos es una cuestión
de trabajar con los registros justos. Por ejemplo, si sólo voy a
trabajar con un registro, lo suyo es que el dataset sólo contenga ese
registro. Si voy a llenar un combo desde una tabla, y esta tiene más
campos de los que voy a necesitar en mi combo para el valuemember y el
displaymember, bastaría con usar una vista que sólo contuviera los dos
campos necesarios para evitar traer todos los demás, etc... De todas
maneras, yo no trabajo con grandes proyectos y quizás haya gente que
te pueda aportar mucho más al respecto.

Y si no quieres trabajar con datasets, pues recurre a datareaders para
leer datos y a commands e incluso procedimientos almacenados para
manipularlos. Las posibilidades son muchas y variadas a mi juicio.
Mira, que yo sepa en Java, sólo dispones de un objeto cursor llamado
resultset para recorrer los registros y poco más, lo cual no quiere
decir que esté mal, pero que puede que sea insuficiente para las
necesidades de un desarrollador en un momento dado.


Respuesta Responder a este mensaje
#14 Juan Diego Bueno
04/04/2007 - 06:57 | Informe spam
"Rafael" escribió en el mensaje
news:%
Yo conozco C# mas a nivel academico que otra cosa pero me pregunto, no
habría alguna falta de información en eso que dicen ustedes?
Es de suponerse que a estas alturas deben haber muchas aplicaciones en
produccion en el mercado que esten hechas en C#.NET o VB.NET. Me resisto
a pensar que las cosas sean tan lentas como ustedes dicen.
Sobre todo cuando en el mercado no en todas las empresas encuentra uno
equipos muy potentes para ejecutar las aplicaciones.



Bueno, yo no he dicho que me parezca lento. Generalmente tarda un poco en
establecer la primera conexión y obtener los primeros datos, pero luego
tiene una velocidad aceptable, al menos en cuanto a manejo de datos se
refiere. Y respecto a falta de información... yo he leido y releido sobre el
tema en varios libros, varias fuentes y no hay más, es decir, se trabaja de
esta forma o peor (como cuando se traen datasets con todos los registros y
solo vas a usar uno o unos pocos). Es más, si ves aplicaciones de ejemplo de
Microsoft, muchas de ellas trabajan con datasets tipados.

"Jose Camacho Vaca" escribió
en el mensaje news:
Sobre lo de Crystal, la forma que tu mencionas es exactamente como yo lo
hago
y la verdad yo pense que eso era hacerlo a mano. Tengo poco con C# y la
verdad se me ha hecho una pesadilla, vengo del mundo de VFP donde todo es
mucho mas facil y productivo.





Cuando me refería a hacerlo a mano, estaba hablando de usar datasets
genéricos, que no fueran tipados, sin necesidad de archivos xml de esquema
para su definición. Pero ese tipo de dataset Crystal no lo reconoce

La verdad eso de la velocidad de los datasets y de Crystal es un chiste
mal
hecho, yo creo que mi abuelita corre mas rápido que eso. Es una
verguenza
que MS ofrezca un producto de ese tipo. Y sobre los demas objetos para
menejo de datos la verdad preferí no meterme, porque vi que son en su
mayoria
peores que el dataset.





Yo no se si el problema de velocidad vendrá porque ADO.NET en general sea un
modelo lento, o simplemente por la propia naturaleza de .NET, ya que no
sirve para compilar a código nativo, sino intermedi

De todas formas me dejaste con la duda que mencionaba, porque los dataset
a
pesar de ser typados no respetan algunos de los operadores de sobrecarga,
te
doy un ejemplo:
creo un dataset Recibo con los campos id_recibo (entero), fecha
(datetime) e
importe (double). Lo relleno con una consulta del tipo Select id_recibo,
fecha, importe from recibos where fecha = '20070331' y al momento de
hacer la
siguiente operación: lcTexto >> miDatatable.rows[0]["importe"].tostring("#,#.00")
simplemente no se puede, tengo que primero pasarle al valor a una
variable
temporal double y luego a esa variable hacerle el tostring().
No entiendo porque si en el dataset se le esta diciendo que es un double
porque no tiene los mismo operadores de sobrecarga que una variable
double.





Sí, la verdad es que hay cosas que son un poco raras, aunque quizás (y solo
en este y otros pocos casos), sea como dice Rafael que algo se nos escapa
para digamos, hacerlo más elegante (aunque la verdad es que la MSDN ayuda
poco a este respecto).

Te digo que esta gente de MS, la que hace el C#, tiene mucho que
aprender.





Bueno, a ver que pasa con C# 3.0

Y los de Crystal ni hablar, es una verguenza, tarda 10 segs. en aparecer
un
reporte se 1 hoja en una computadora P4 con 1Gb. de RAM?





Lo de Crystal a mi si me parece flagrante. A mi un informe de tipo ficha con
140 registros me tarda mínimo 4 segundos y como he dicho repetidas veces
aquí, eso es tirando de datasets. Es más, si según se abre el informe quiero
ir a la última página, me tarda otros cuatro o cinco segundos. Si lo hago
directamente de la base de datos, me tarda el doble. En este proyecto en el
que estoy no me voy a poner a mezclar tipos de informe, pero para sucesivos
voy a plantearme seriamente usar reporting services porque es infinitamente
menos pesado en la carga y ofrece una funcionalidad muy similar

Saludos

José Camacho Vaca
Colima, MX


"Juan Diego Bueno" wrote:

On 3 abr, 17:48, Jose Camacho Vaca
wrote:
> Perdon por la intromisión, pero a que te refieres con "no hacerlo a
> mano" en
> el caso de Crystal.

Me refiero a que en Crystal, para poder usar datasets como fuente de
datos, éstos han de ser tipados. Es decir, si yo inserto un dataset
genérico, Crystal no se va a enterar de su existencia. Al ser así, si
tu quieres por ejemplo, hacer un informe basado en un filtrado por la
aplicación, si no quieres usar datasets, te quedaría el recurso de
crear una vista o tabla temporal de la que tirara el informe. A mi, ya
que uso el filtrado en la aplicación para un grid, me gusta que me
pueda servir también para el informe (no se si se ha entendido).

> Otra duda por favor. Yo uso mucho los datasets, por las ventajas que
> tu
> mencionas pero me extraña mucho que aunque sean fuertemente tipados:
> 1) no
> manejan todos los tipos de datos nativos de SQLServer, 2)No en todos
> los
> tipos tienes todos los operadores de sobrecarga. Pongo ejemplo: 1)No
> tienen
> el tipo money, 2)Cuando en un dataset tienes un campo tipo double y le
> quieres hacer un ToString() pero con formato no se puede, primero lo
> tienes
> que meter a una variable temporal que sea tipo double y luego hacerle
> es
> ToString() con formato.

Lo de "fuertemente tipados" es una traducción literal mía de "strongly
typed datasets" de un artículo que leí cuando comenzaba con crystal
y .net que explicaba como poder hacer que tiraran de datasets en vez
de directamente de la base de datos. Lo de fuertemente tipados viene,
si no me equivoco, por lo específicos que son. Cuando tu creas un
dataset de este tipo, el dataadapter es específico de esa tabla
(tableadapter), etc... (Yo es que no se explicar muy bien esto, pero
lee más posts que hay gente que lo explica mejor que yo)

> No conocen alguna forma de que todo eso no sea tan tardado.
> Gracias por sus sugerencias y un saludo.

Lo de la velocidad a la hora de tratar con los datos es una cuestión
de trabajar con los registros justos. Por ejemplo, si sólo voy a
trabajar con un registro, lo suyo es que el dataset sólo contenga ese
registro. Si voy a llenar un combo desde una tabla, y esta tiene más
campos de los que voy a necesitar en mi combo para el valuemember y el
displaymember, bastaría con usar una vista que sólo contuviera los dos
campos necesarios para evitar traer todos los demás, etc... De todas
maneras, yo no trabajo con grandes proyectos y quizás haya gente que
te pueda aportar mucho más al respecto.

Y si no quieres trabajar con datasets, pues recurre a datareaders para
leer datos y a commands e incluso procedimientos almacenados para
manipularlos. Las posibilidades son muchas y variadas a mi juicio.
Mira, que yo sepa en Java, sólo dispones de un objeto cursor llamado
resultset para recorrer los registros y poco más, lo cual no quiere
decir que esté mal, pero que puede que sea insuficiente para las
necesidades de un desarrollador en un momento dado.








Respuesta Responder a este mensaje
#15 [Juanjo]
04/04/2007 - 10:44 | Informe spam
Buenos dias:

Soy de las personas que piensan que una cosa no es mejor que otra o
peor, si no que puede
tener cosas buenas o mejores para unas cosas y peores o no tan buenas para
otras. Con esto
que quiero decir, por ejemplo: Un DataSet tipado es mejor que hacerlo a
mano? Es posible
que si o no. Cada uno tiene su experiencia. Es cierto que si tu miras el
fichero que gener el
Dataset.designer.cs tiene 1000 lineas (mas bien es 1000 lineas por cada
consulta) es cierto,
tambien es cierto que de las 1000 lineas, la mitad de ellas son definiciones
de tipos de datos, y la
otra mitad es la comprobacion de los parametros. Que mas da que tu
compruebes los parametros
o que los comprueben por ti??? Pues habra veces que interese no
comprobarlos, no se.

Respecto a los tipos de datos fuertemente tipados, que comenta Jose
Camacho, creo que
depende tambien del motor de la base de datos. Yo con tipo de dato fecha no
he tenido problema
en guardarla en un campo fecha sobre una base de datos SQL Server, pero
cuanto he tenido
que hacer una consulta "a pelo" sobre Access he tenido que cambiar el orden
de los dias, meses y años,
y sobre VFP ademas usar la funcion date.

Crystal y Visual Studio es para comer a parte, de hecho hay un hilo mas
abajo en el cual hay
una "especie de estudio" de como hacer mejor o peor una informe. Alguien ha
pensado si es un
problema entre el Crystal y el SQL Server por ejemplo? Vuelvo a comentar un
problema que he visto
en Crystal (porque lo he probado): Cuando haces un informe en Crystal, el
Crystal no hace el "where"
sobre la base de datos, si no que trae todos los datos y luego hace el
filtro (esto lo podeis ver si mostrais
la consulta que genera el Crystal, no lo estoy inventando, y las pruebas las
hice sobre 150.000 registros)
por esto mismo, yo personalmente, prefiero pasarle al crystal un dataset
tipado con los datos, para
que no tenga que hacer el Crystal la consulta.

No quiero decir que VC#, SQL Server y Crystal sea el mejor invento
despues de las patatas fritas con
huevos ni mucho menos. Yo cuando lo necesito uso los Dataset tipados y
cuando no, hago mi consulta a
pelo. Tampoco trato de convencer a nadie. Solo digo que cada uno use lo que
mejor le venga o interese
en cada momento, en ningun sitio esta escrito que te tengas que casar con
una forma de trabajar.

Un saludo.


"Pedro" escribió en el mensaje
news:
Alguien ha visto cuando uno agrega un dataset (y sus tablas) en un
formulario visualmente la cantidad de codigo que se genera internamente en
Dataset.designer.cs?
Pregunto, es necesario todo eso para trabajar con datos. Como le hago si
no quiero trabajar con dataset o por lo menos de esa manera?

Pedro

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