DataSet vs clases propias

Bueno, por si sirve de algo, yo también provengo de
Delphi, aunque hace tantos años que no lo toco que apenas
lo recuerdo. No se cuanto habrá prosperado Delphi desde
entonces, pero no echo de menos nada. En especial tengo
muy mal recuerdo del BDE, aunque espero que hayan surgido
cosas más eficientes desde entonces.

Sobre tu pregunta:

¿Y como se conecta un dataset sin escribir código?

Es que realmente esa es la clave. En esta versión de
ado.net, no se puede conectar un dataset. Para las
consultas en modo conectado tenemos DataReader. De todas
formas, no me gusta enlazar datos directamente con el
interface de usuario. ¿A eso te refieres?

Pero lo interesante es que si puedes crear un DataReader
sin prácticamente escribir código. El diseñador de
windows forms permite crear comandos en tiempo de diseño.
Para obtener un datareader tan solo hay que escribir un
ExecuteReader.

De todas formas, para los que no se sienten cómodos con
esta filosofía de trabajo, se sigue pudiendo utilizar
ADO, y sus tradicionales cursores de servidor. Yo no lo
recomendaría, pero ahí está.

Pero de todas formas, no estoy de acuerdo en que no se
deba utilizar nunca un modo desconectado.

Siempre habrá muchas circunstancias en que sea preferible
trabajar de forma desconectada. Ya sea para minimizar las
conexiones abiertas, para reducir el tráfico de red, por
tratarse de equipos desconectados, o por una infinidad de
otras razones. De hecho, muchas aplicaciones utilizaban
xml para esto. Ado.net tan solo simplifica el trabajo.
Además, con las posibilidades de XQuery, posiblemente la
capacidad de consulta desconectada supere incluso la
flexibilidad de SQL.

En resumen, yo creo que la decisión ha sido bastante
correcta. Un modo desconectado con limitadas (aunque
potentes) capacidades relacionales, y un modo conectado
para el acceso completo al SGBD.

On Mon, 20 Dec 2004 10:16:12 -0800, "Tristan"
wrote:

En especial tengo
muy mal recuerdo del BDE, aunque espero que hayan surgido
cosas más eficientes desde entonces.

Han surgido muchas alternativas al BDE, el BDE se considera obsoleto
desde hace bastantes años. Yo nunca he llegado a utilizar el BDE para
conectarme a un SGBD.

De todas formas a Delphi le veo muy poco futuro. VS.Net se lo está
comiendo a pasos agigantados. Ultimamente Delphi se está buscando un
nicho entre los peores programadores: los que usan colecciones
personalizadas para gestionar los datos desde dentro de las
aplicaciones.

Sobre tu pregunta:

¿Y como se conecta un dataset sin escribir código?

Es que realmente esa es la clave. En esta versión de
ado.net, no se puede conectar un dataset.

Pues entonces es lo que yo decía. Yo estaba criticando a los datasets,
por que se han creado para trabajar desconectados, y eso es un
disparate a menos que sigamos disponiendo de toda la funcionalidad del
SGBD.

Para las
consultas en modo conectado tenemos DataReader.

Que no es más ni menos que una clase que encapsula a un cursor
unidireccional de solo lectura. Un cursor y de los peores. Pero la
discusión era acerca de los datasets.

En tu otro mensaje decías que no debían de usarse cursores y estoy de
acuerdo.

Aquí hay un artículo bastante interesante.

http://www.monografias.com/trabajos...html#OBJET

Algunas citas:



El objeto DataReader es, en cierto modo, sinónimo de un cursor de sólo
lectura y sólo hacia delante para datos.

El objeto DataSet es similar al objeto Recordset de ADO, pero más
eficaz y con una diferencia importante: DataSet siempre está
desconectado.

De todas
formas, no me gusta enlazar datos directamente con el
interface de usuario. ¿A eso te refieres?

Me refiero a enlazar el interfaz de usuario con el SGBD de la forma
más sencilla posible.

Me imagino que no estarás en contra de que las cosas sean sencillas de
hacer, siempre que no perdamos rendimiento ni flexibilidad. Esto puede
conseguirse.

Pero lo interesante es que si puedes crear un DataReader
sin prácticamente escribir código. El diseñador de
windows forms permite crear comandos en tiempo de diseño.
Para obtener un datareader tan solo hay que escribir un
ExecuteReader.

Pero no es más que un vulgar cursor. No se puede conectar directamente
a un formulario Windows con campos de lectura y escritura.

De todas formas, para los que no se sienten cómodos con
esta filosofía de trabajo, se sigue pudiendo utilizar
ADO, y sus tradicionales cursores de servidor. Yo no lo
recomendaría, pero ahí está.

¿Como puede hacerse? ¿Tienes alguna referencia?

Me podría ser bastante útil mientras no acabe de implementar un
sustituto para los datasets.


Saludos
Alfredo

On Mon, 20 Dec 2004 10:25:34 -0800, "Tristan"
wrote:

Pero de todas formas, no estoy de acuerdo en que no se
deba utilizar nunca un modo desconectado.

Siempre habrá muchas circunstancias en que sea preferible
trabajar de forma desconectada. Ya sea para minimizar las
conexiones abiertas

Eso se soluciona mejor con un "middleware". Pero ¿Por que querríamos
minimizar las conexiones abiertas?

¿Para ahorrarnos dinero en las licencias?

Creo que en algunos casos hacer esto puede considerarse como un
fraude.

Si es por motivos de rendimiento o aprovechamiento de recursos
entonces es que el SGBD no gestiona muy bien las conexiones.

, para reducir el tráfico de red

Esto se soluciona mucho mejor usando un SGBD distribuido.

Los datasets se podrían considerar como un antepasado prehistórico de
un SGBD distribuido.

Por ejemplo si estamos trabajando con un SGBD distribuido y hacemos
una consulta SQL que afecta a datos que se encuentran en el PC local
el tráfico de red sería 0 y seguimos con todas las ventajas de estar
conectados.

En el caso en que solo la mitad de los datos se encontrasen en el PC
local solo haría falta traer la mitad de los datos, y esto se haría de
forma totalmente automática y transparente. Si repetimos la consulta y
el PC local tiene capacidad suficiente entonces el trafico de red
sería otra vez 0. Un SGBD distribuido funciona como una caché super
sofisticada.

Es decir que el programador trabajaría de la misma forma que si
estuviese programando una aplicación de escritorio y sería el SGBD el
que se encargase de minimizar el tráfico de red sin que tuviesemos que
preocuparnos de nada. Esto no es ciencia ficción, es un problema
resuelto hace décadas.

Un middleware relacional haría exactamente lo mismo.

, por
tratarse de equipos desconectados, o por una infinidad de
otras razones.

Te digo lo mismo. Hay soluciones mucho mejores desde hace décadas, los
datasets son la reinvención de la cachiporra.

De hecho, muchas aplicaciones utilizaban
xml para esto.

Ya, no hay nada por mal que esté que no pueda hacerse peor :)

Además, con las posibilidades de XQuery, posiblemente la
capacidad de consulta desconectada supere incluso la
flexibilidad de SQL.

Hablando de ruedas cuadradas... :). Mejor no hablemos de XQuery :)

Un rápido enlace: http://c2.com/cgi-bin/wiki?ModernDinosaur


Saludos
Alfredo

Eso se soluciona mejor con un "middleware". Pero ¿Por
que querríamos minimizar las conexiones abiertas?
¿Para ahorrarnos dinero en las licencias?
Creo que en algunos casos hacer esto puede considerarse
como un fraude.

Segun lo que lee de tu posicion piensas que seria mejor
trabajar con conexiones abiertas en vez de desconectadas
como propone el modelo de ado.net y que es SGBD carge con
el peso de las mismas. Pero en nuestras aplicaciones que
podrian tener cientos o miles de usuarios concurrentes
esto seria una peso bastante grande no es mejor en este
sentido que se conecten y desconecten para ahorrar
recursos no solo del SGSB sino de toda la PC???

Una solución más flexible es crear un "middleware"
relacional. Es
decir un "motor" relacional que se ejecutaría localmente
y se
conectaría a un SGBD remoto de cualquier fabricante
cuando hiciese falta. Algo del estilo de DataJoiner de
IBM. Este "middleware" debería
tener una interfaz relacional, y trabajaríamos siempre
conectados a él.

No entiendo bien este punto, acaso dices que cada cliente
debe tener una copia local de su BD. por que eso seria
carisimo!. No se si me explicas mejor.

gracias a todos por sus comentarios