Para que sirve LINQ?

21/10/2008 - 03:16 por Anti_Work | Informe spam
Hola.
Estaba mapeando objetos a sql server 2005. El problema era el siguiente:
Tengo un objeto Empresa que tiene un conjunto de objetos Licitacion, Cada
Licitacion tiene un conjunto de objetos Articulo, los cuales, as su vez
tienen un objeto Proveedor. Como la empresa debe conocer a sus proveedores,
tambien tiene una coleccion de Proveedor. Tambien tenemos la coleccion de
objetos Entrega, etc, etc.
Imaginense lo que es mapear todo esto a una base de datos, por ejemplo para
agregar una Licitacion ¡¡todo lo que hay que verificar para asegurarnos que
no falle!! ¿Y si eliminamos una Licitacion...!!?

Asi que me puse a ver un poco por arriba LINQ. Enseguida me di cuenta que
LINQ con su diseñador, hace todo esto (y mucho mas). Todo lo que tenemos que
hacer es arrastrar las tablas con el mouse. Tal vez sea un problema el hecho
de que a veces nuestro diseño de objetos no coincide exactamente con el de la
DB, pero seguramente no debe ser muy dificil solucionarlo.
Lo que tambien pude ver, es que todo luce como para usarlo como un origen de
datos. Y aunque no me interiorice mucho en esto, me pregunto ¿para que? ¿para
que agregar una capa más? si al final terminaremos con un dataset tipado o
algo asi. ¿por que no conectar el origen de datos directamente a la base de
datos?.
Y aqui la corto por ya se me fue la mano (o la lengua).

Saludos

Preguntas similare

Leer las respuestas

#1 Alfredo Novoa
21/10/2008 - 11:42 | Informe spam
Hola,

El Mon, 20 Oct 2008 18:16:01 -0700, Anti_Work escribió:

Hola.
Estaba mapeando objetos a sql server 2005. El problema era el siguiente:
Tengo un objeto Empresa que tiene un conjunto de objetos Licitacion, Cada
Licitacion tiene un conjunto de objetos Articulo, los cuales, as su vez
tienen un objeto Proveedor. Como la empresa debe conocer a sus proveedores,
tambien tiene una coleccion de Proveedor. Tambien tenemos la coleccion de
objetos Entrega, etc, etc.
Imaginense lo que es mapear todo esto a una base de datos, por ejemplo para
agregar una Licitacion ¡¡todo lo que hay que verificar para asegurarnos que
no falle!! ¿Y si eliminamos una Licitacion...!!?



Pues si, es estupendo para alargar el tiempo de desarrollo y complicar el
mantenimiento.

Asi que me puse a ver un poco por arriba LINQ. Enseguida me di cuenta que
LINQ con su diseñador, hace todo esto (y mucho mas). Todo lo que tenemos que
hacer es arrastrar las tablas con el mouse. Tal vez sea un problema el hecho
de que a veces nuestro diseño de objetos no coincide exactamente con el de la
DB, pero seguramente no debe ser muy dificil solucionarlo.



No es difícil. Eliminas el modelo de objetos y ya está.

Lo que tambien pude ver, es que todo luce como para usarlo como un origen de
datos. Y aunque no me interiorice mucho en esto, me pregunto ¿para que? ¿para
que agregar una capa más? si al final terminaremos con un dataset tipado o
algo asi. ¿por que no conectar el origen de datos directamente a la base de
datos?.



No se muy bien a que te refieres con "origen de datos". Pero se supone que
si usas LinQ ya no necesitas datasets.

LinQ pretende evitar el uso de SQL incrustado en las aplicaciones y
permitir la verificación de las consultas en tiempo de compilación. El
problema es que solo lo consigue en parte por que hay muchas consultas que
no se pueden hacer en LinQ y hay que hacerlas en SQL de todas formas.
Además de esto LinQ tiene muchos otros defectos por haber sido diseñado por
gente que no tiene ni idea de bases de datos.


Saludos
Respuesta Responder a este mensaje
#2 Anti_Work
22/10/2008 - 03:01 | Informe spam
yo pensaba que cuando creas un origen de datos, ese del cual se pueden
arrastrar los campos al form ya te crea los texbox, combos, etc para mostrar
los datos, lo que se crea es un dataset tipado. Pero si no es asi, lo que
dije de una capa de mas, no corresponde.
A mi, lo que en realidad me interesa es mapear objetos a db, ya que las db
orientada a objetos no parecen ser una buena opción.
En cuanto a eliminar el modelo de datos: es justamente lo que no quiero
hace, desperdiciar las ventajas que no da el paradigma de POO.

saludos
Respuesta Responder a este mensaje
#3 Alfredo Novoa
22/10/2008 - 11:05 | Informe spam
El Tue, 21 Oct 2008 18:01:00 -0700, Anti_Work escribió:

yo pensaba que cuando creas un origen de datos, ese del cual se pueden
arrastrar los campos al form ya te crea los texbox, combos, etc para mostrar
los datos, lo que se crea es un dataset tipado. Pero si no es asi, lo que
dije de una capa de mas, no corresponde.



Te repito que LinQ no está pensado para trabajar con los datasets, aunque
se creen al arrastrar campos al formulario.

A mi, lo que en realidad me interesa es mapear objetos a db, ya que las db
orientada a objetos no parecen ser una buena opción.



Pues por las mismas razones por las que las bases de datos orientadas a
objetos no son una buena opción, lo que intentas hacer tampoco lo es.

En cuanto a eliminar el modelo de datos:



Te había dicho eliminar el modelo de objetos.

es justamente lo que no quiero
hace, desperdiciar las ventajas que no da el paradigma de POO.



Por eso es mejor eliminar el modelo de objetos, por que el "paradigma" de
POO no da ventajas para gestionar datos :-)

A no ser que tu objetivo sea maximizar los costes de desarrollo y
mantenimiento, entonces adelante.


Saludos
Respuesta Responder a este mensaje
#4 Anti_Work
22/10/2008 - 23:47 | Informe spam
Como dije al principio, mi objetivo es trabajar con el modelo de Objetos. He
leido por todas partes que apegarse a un adecuado diseño de objetos hace que
la aplicacion sea mas facil de mantener y escalar, y tambien puede reducir la
complejidad.
Yo hice, con vb6, algunas aplicaciones que terminaron siendo muy complejas y
cuesta mucho cada vez que hay hacer alguna modificacion. Ahora que estoy
aprendiendo POO, me doy cuenta que habria sido mucho mas facil si lo hubiera
hecho con objetos. Mas facil para programar, depurar, hacer modificaciones y
agregar funcionalidad. Algunas de la modificaciones que me llevaron mucho
trabajo porque cada cambio impactaba en muchos lugares, con objetos lo
hubiera hecho con solo agregar una clase.
Pero el problema de trabajar con un modelo de objeto es mapear a la base de
datos, entonces toda las ventajas que tiene la POO, al final son superadas
por las complicaciones de la persistencia.

Saludos
Respuesta Responder a este mensaje
#5 Alfredo Novoa
23/10/2008 - 09:50 | Informe spam
El Wed, 22 Oct 2008 14:47:01 -0700, Anti_Work escribió:

Como dije al principio, mi objetivo es trabajar con el modelo de Objetos. He
leido por todas partes que apegarse a un adecuado diseño de objetos hace que
la aplicacion sea mas facil de mantener y escalar, y tambien puede reducir la
complejidad.



Pues un modelo como el que comentabas en tu primer mensaje no es adecuado y
va a hacer todo lo contrario de lo que esperas.

Yo hice, con vb6, algunas aplicaciones que terminaron siendo muy complejas y
cuesta mucho cada vez que hay hacer alguna modificacion. Ahora que estoy
aprendiendo POO, me doy cuenta que habria sido mucho mas facil si lo hubiera
hecho con objetos.



Pues yo aprendí POO hace más de 15 años y hace unos cuantos años me di
cuenta de que si dejas que el SGBD se ocupe de todo lo que es la gestión de
datos y que las aplicaciones se ocupen de la presentación y la comunicación
con los usuarios todo es mucho más fácil.

Mas facil para programar, depurar, hacer modificaciones y
agregar funcionalidad. Algunas de la modificaciones que me llevaron mucho
trabajo porque cada cambio impactaba en muchos lugares, con objetos lo
hubiera hecho con solo agregar una clase.



Todo esto está muy bien siempre que sepas separar las responsabilidades de
la aplicación y del SGBD. La aplicación se debe de ocupar de la
presentación y el SGBD de la gestión de los datos, es decir, de las "reglas
de negocio".

Pero el problema de trabajar con un modelo de objeto es mapear a la base de
datos, entonces toda las ventajas que tiene la POO, al final son superadas
por las complicaciones de la persistencia.



Señal de que estás haciendo algo muy mal, por que las aplicaciones no
tienen que ocuparse de la persistencia, eso es tarea del SGBD. Eso es señal
de que estás intentando gestionar los datos desde la aplicación en lugar de
dejar que el SGBD se encargue de eso. Este es uno de los peores
antipatrones que hay.


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