NHibernate vs Linq vs DataSet vs CastleProject

Hola jcp

escribió en el mensaje de
noticias:

hola no sé mucho de esto pero he estado leyendo sobre nhibernate y
recientemente sobre linq parece que conceptualmente es lo mismo es
decir son ORM mi pregunta es

Yo no conozco mucho hibernate ni nhibernate pero aunque con similitudes, no
veo que sean igual que LinQ. Principalmente porque hasta donde yo sé, no
permiten integrar las consultas en el lenguaje. Una cosa es que se los
objetos del SGBD y tengamos métodos para poder obtener sus manipularlos y
otra que el lenguaje te deje hacer un select sobre ellos como haces con
LinQ.

¿cual es mejor ? para trabajar yo siempre

he utilizado los DataSet como un ORM pero he leído en arŽticulos que
los dataset no son una buena opión al momento de desarrollar
aplicaciones grandes así que si es cierto eso me gustaría escuchar de
los expertos y de la gente que ha manejado cualquiera de estos ORMs
cuál es el mejor tanto en su aprendizaje (keno tenga una curva de
aprenidzaje muy pronunciada), y que sea muy robusta es decir que pueda
abarcar la mayoriaa de los diseños de base de datos y de clases
gracias por sus respuestas

Cuando hablas de datasets como ORM, supongo que te refieres a los datasets
fuertemente tipados. Supongo que el problema es el mismo que con cualquier
ORM, y es que generan código a cascoporro con funcionalidades que luego tu
no acabas usando. Yo aun los uso, sobre todo para informes, ya que aun no he
dado con la forma eficaz de poder usar crystal o reporting con datasets o
datatables no tipados, pero básicamente me he dado cuenta que con datatables
y datasets por código tardas más o menos lo mismo en diseñar y no llevan
tanto código innecesario. Y luego está el handicap más grande para mi de los
datasets tipados, y es lo mucho que te atan a un servidor concreto. Es
decir, cuando yo utilizo datasets tipados, lo primero que me pide al agregar
una tabla es una conexión de datos, cuya cadena de conexión queda almacenada
en el código fuente. Si le dices que guarde la contraseña, tendrás un bonito
regalo para el que decompile tu código, si le dices que no la guarde, o no
te funciona, o vas a tener que anexársela tu de forma dinámica. Por otra
parte, también estás limitado a conectarte a ese servidor que aparece en la
cadena de conexión. No es difícil cambiarla por código, el problema es que
cada vez que quieres incluir una nueva tabla o modificar ese dataset,
vuelves a tener que incluir esa cadena de conexión para poder seguir
desarrollando. No es la primera vez que tengo problemas al distribuir una
aplicación y encontrarme con la desagradable sorpresa de que está tomando
datos de un servidor y grabándolos en otro porque en alguna parte no quedó
reajustada la cadena de conexión. En fin, un coñazo...

Eso no deja de ser mi experiencia. Yo te recomiendo que pruebes diferentes
opciones y te quedes con la que mejor se adapte a tu forma de trabajar.

Saludos

Juan Diego Bueno wrote:

Hola jcp

escribió en el mensaje de
noticias:

hola no sé mucho de esto pero he estado leyendo sobre nhibernate y
recientemente sobre linq parece que conceptualmente es lo mismo es
decir son ORM mi pregunta es

Yo no conozco mucho hibernate ni nhibernate pero aunque con similitudes,
no veo que sean igual que LinQ. Principalmente porque hasta donde yo sé,
no permiten integrar las consultas en el lenguaje. Una cosa es que se
los objetos del SGBD y tengamos métodos para poder obtener sus
manipularlos y otra que el lenguaje te deje hacer un select sobre ellos
como haces con LinQ.

Que eventualmente el compilador las traducirá a llamadas a clases y
métodos. En mi opinión, es bueno que no esté integrado al lenguaje, la
sintaxis es horrible y agrega una sobrecarga inecesaria al lenguaje.

¿cual es mejor ? para trabajar yo siempre
he utilizado los DataSet como un ORM pero he leído en arŽticulos que
los dataset no son una buena opión al momento de desarrollar
aplicaciones grandes así que si es cierto eso me gustaría escuchar de
los expertos y de la gente que ha manejado cualquiera de estos ORMs
cuál es el mejor tanto en su aprendizaje (keno tenga una curva de
aprenidzaje muy pronunciada), y que sea muy robusta es decir que pueda
abarcar la mayoriaa de los diseños de base de datos y de clases
gracias por sus respuestas

Cuando hablas de datasets como ORM, supongo que te refieres a los
datasets fuertemente tipados. Supongo que el problema es el mismo que
con cualquier ORM, y es que generan código a cascoporro con
funcionalidades que luego tu no acabas usando.

Un O/RM no necesariamente es fuertemente tipado. En el caso de ADO.NET
con los DataSets personalizados, sí es un problema y se cumple lo que
afirmas. En el caso de NHibernate, no, porque lo que se hace es un
verdadero mappeo entre tabla y clase, y entre registro y objeto. No te
genera código, todo está encapsulado en una librería contra la que hay
que enlazar.

Todo se hace a través de Reflection. Guardas unos archivos XML como
recurso del sistema donde mappeas la tabla a tu clase. Luego, el engine
de NHibernate lee dichos archivos, carga objetos y asigna valores a las
propiedades mappeadas. Por supuesto, hay varias técnicas (como un
lenguaje que crearon para hacer consultas, algo remotamente similar a
Linq to SQL, pero sin extensiones al lenguaje.

Yo aun los uso, sobre
todo para informes, ya que aun no he dado con la forma eficaz de poder
usar crystal o reporting con datasets o datatables no tipados, pero
básicamente me he dado cuenta que con datatables y datasets por código
tardas más o menos lo mismo en diseñar y no llevan tanto código
innecesario. Y luego está el handicap más grande para mi de los datasets
tipados, y es lo mucho que te atan a un servidor concreto. Es decir,
cuando yo utilizo datasets tipados, lo primero que me pide al agregar
una tabla es una conexión de datos, cuya cadena de conexión queda
almacenada en el código fuente. Si le dices que guarde la contraseña,
tendrás un bonito regalo para el que decompile tu código, si le dices
que no la guarde, o no te funciona, o vas a tener que anexársela tu de
forma dinámica.

Por supuesto, agregársela de forma dinámica es como la mejor opción. En
cualquier otro caso, está expuesta --como dices-- a quien decompile el
código.

Por otra parte, también estás limitado a conectarte a
ese servidor que aparece en la cadena de conexión. No es difícil
cambiarla por código, el problema es que cada vez que quieres incluir
una nueva tabla o modificar ese dataset, vuelves a tener que incluir esa
cadena de conexión para poder seguir desarrollando.

Eso normalmente se soluciona con polimorfismo. :)

No es la primera vez
que tengo problemas al distribuir una aplicación y encontrarme con la
desagradable sorpresa de que está tomando datos de un servidor y
grabándolos en otro porque en alguna parte no quedó reajustada la cadena
de conexión. En fin, un coñazo...

Eso no deja de ser mi experiencia. Yo te recomiendo que pruebes
diferentes opciones y te quedes con la que mejor se adapte a tu forma de
trabajar.

Como ultimo comentario, más dirigido al OP, acabo de leer que LINQ to
SQL solo funciona con SQL Server, así que si se quiere emplear otras
bases de datos, creo que LINQ no sería una solución.

Saludos.

Hola Fernando,

El Tue, 01 Jul 2008 18:01:05 -0500, Fernando Gómez escribió:

Una cosa es que se
los objetos del SGBD y tengamos métodos para poder obtener sus
manipularlos y otra que el lenguaje te deje hacer un select sobre ellos
como haces con LinQ.

Que eventualmente el compilador las traducirá a llamadas a clases y
métodos.

Eventualmente no. Siempre. Igual que el compilador JIT las traducirá a
código máquina. No se a donde quieres ir a parar con eso.

En mi opinión, es bueno que no esté integrado al lenguaje, la
sintaxis es horrible y agrega una sobrecarga inecesaria al lenguaje.

Pues en mi opinión y en la de muchos expertos es muy bueno que esté
integrado en el lenguaje, pero la sintaxis es horrible y tiene fallos
garrafales increibles como el que no existan instrucciones de actualización
y que tengas que definir clases que correspondan con las tablas.

Todo se hace a través de Reflection. Guardas unos archivos XML como
recurso del sistema donde mappeas la tabla a tu clase. Luego, el engine
de NHibernate lee dichos archivos, carga objetos y asigna valores a las
propiedades mappeadas. Por supuesto, hay varias técnicas (como un
lenguaje que crearon para hacer consultas, algo remotamente similar a
Linq to SQL, pero sin extensiones al lenguaje.

Es decir, que tiene algunos de los inconvenientes de LinQ sin sus ventajas.

Como ultimo comentario, más dirigido al OP, acabo de leer que LINQ to
SQL solo funciona con SQL Server, así que si se quiere emplear otras
bases de datos, creo que LINQ no sería una solución.

Pero el LinQ to Entities va a funcionar con diferentes SGBD.


Saludos
Alfredo

El Tue, 1 Jul 2008 08:19:43 -0700 (PDT), escribió:

hola no sé mucho de esto pero he estado leyendo sobre nhibernate y
recientemente sobre linq parece que conceptualmente es lo mismo es
decir son ORM mi pregunta es ¿cual es mejor ?

Eso es un poco como preguntar: ¿Cuál es mejor, la peste o el hambre? }:-)

para trabajar yo siempre
he utilizado los DataSet como un ORM pero he leído en ar´ticulos que
los dataset no son una buena opión al momento de desarrollar
aplicaciones grandes

Eso se referirá a los datasets tipados, los no tipados son igual de malos
para aplicaciones grandes o pequeñas.

así que si es cierto eso me gustaría escuchar de
los expertos y de la gente que ha manejado cualquiera de estos ORMs
cuál es el mejor

Yo creo que lo menos malo son los datasets no tipados, aunque siguen siendo
muy malos. Otra alternativa es usar directamente los SqlCommand.


Saludos
Alfredo

Hola Juan Diego,

El Tue, 1 Jul 2008 23:16:44 +0200, Juan Diego Bueno escribió:

Cuando hablas de datasets como ORM, supongo que te refieres a los datasets
fuertemente tipados. Supongo que el problema es el mismo que con cualquier
ORM, y es que generan código a cascoporro con funcionalidades que luego tu
no acabas usando. Yo aun los uso, sobre todo para informes, ya que aun no he
dado con la forma eficaz de poder usar crystal o reporting con datasets o
datatables no tipados,

¿Pero por que quieres usar Crystal Reports con datasets?

No le veo sentido, lo lógico es que los informes de Crystal saquen los
datos directamente del SGBD.


Saludos
Alfredo