DESARROLLO EN 3 CAPAS

On Fri, 25 Nov 2005 15:27:53 -0300, "Cristian Ledesma"
wrote:

Bueno lo que quise decir es lo Sgte, en ejemplo que he visto en muchos que
no entiendo pq esta asi , la gente Crea Clases ejemplo (Person,Cliente,
proveedores) que continen propiedades y se puede acceder por Get y Set y
todo lo que implica eso,

Ya, eso si que lo entendí. Lo que pasa es que llamar a eso "clases
para la persistencia" es una barbaridad. En realidad son clases para
gestionar los datos en la aplicación usando código procedimental y a
base de recorrer laberintos de punteros.

Esta forma de trabajar quedó obsoleta hace décadas. Pero los que no
conocen el pasado están condenados a repetirlo.

Pero yo si que entiendo por que lo hacen así. Por que no conocen los
fundamentos de su profesión. Así de claro.

el punto es que pongamos un ejemplo practico tengo
3 Textbox (txtClienteId,txtNombre,txtTelefono) en ves de atomatizar esto
directamente sobre el DataTable lo que hacen es

Cliente.Clienteid = txtClienteId
Cliente.Nombre = txtNombre
Cliente.Telefono = txtTelefono

Luego la Clase Cliente de nuevo tiene un Metodo Actualizar que es el que
realmente dispara el comando SQL contra la BAse de datos, ahora bien lo
improductivo de esto creo yo el lo sgte.

1.- Los DataSet's ya trabajan desconectados.

Y esto es una cosa muy mala por que te obliga a verificar los datos
otra vez en la aplicación con medios muy primitivos (código
procedimental). Por ejemplo antes de insertar un "Item" en la
colección tienes que comprobar un montón de cosas.

Por suerte esto se arregla en parte con los TableAdapter, que
comunican los cambios inmediatamente al SGBD. Así parece que los
DataSet trabajan conectados.

2.- No puedo Saber el Status del Registro (Si ha sufrido Cambios etc).

Ni tampoco puedes saber muchas cosas más. Por ejemplo si el artículo
que intentas vender ya ha sido vendido, o si el código que quieres
usar ya ha sido usado. Puedes tener problemas de concurrencia de todo
tipo.

3.- Es como reinventar la rueda ,puesto a que el DataSet ya es una clase.

Y además una clase genérica reutilizable, mientras que las otras solo
sirven para una vez.

Lo que si que creo que puede ser bueno es crear algo parecido a los
Dataset, pero sin cometer los mismos errores.

4.-No veo diferencias en Performance, Puesto a que si trabajamos con
DataTables Parametrizados y traemos solo los Registros necesarios como debe
ser en una programacion C/S no hay diferencias.

Exacto, aunque para hacer esto los DataSet ayudan bastante poco.

5.- Es muy trabajoso pq como seria para un Maestro/Detalle (el Maestro Seria
Una Clase y el Detalle Una Clase Tipo Array[]) para que pueda guardar los
Items

Y además es un esfuerzo inútil.

Tardar 4 días para hacer una aplicación que se podría hacer en una
tarde no es un gran problema, pero si tardas 4 años para una
aplicación que se podría hacer en 6 meses entonces si que se nota
bastante la diferencia.

Aunque si eres un desaprensivo y facturas por horas entonces lo de las
clases estas te puede venir de maravilla. Para algunas cosas lo peor
es lo mejor.

ademas existen otras Tecnicas tales como RemoteObjetcs y otras persistencias
como se usa en Java.

Si, pero suelen cometer los mismos pecados.

Basicamente esto del DataSet para mi no es nuevo puesto aque e trabajo con
Delphi y en la Version 2.0 ya teniamos esto implementado,

Yo incluso desde la 1.0.

se que a lo mejor estoy un poco confuso pero no en el Curso 5 Estrellas
nadie me ha podido explicar pq no usan los
txtClienteId,txtNombre,txtTelefono sobre el DataSet siendo que esto ahoraria
mucho trabajo e inclusibe en Vs2005 existe es BindingContext o DataBinding
el cual manejaria esto,

No eres tu precisamente el que anda confuso.

para terminar no me imagino lo que seria hacer un Reporte con la
Persistencia de este tipo en Clases.

Yo desgraciadamente si se lo que es: un horror.


Saludos
Alfredo

On Fri, 25 Nov 2005 22:27:10 -0500, "rafael"
wrote:

Bueno en .net existe datatable pero en vb6 no, solo esta el archiconocido
recordset, que trabaja de forma conectada.

Pues más fácil lo tienes.

Yo conozco a gente que no quiere pasarse a .Net precisamente por eso.

Saludos

Bueno alfredo hasta ahora no he visto plasmado la forma en que envias los
datos a la bd.
Con funciones
Public function Grabar(Parametro1, par2,.parN)

end function
o como?
en vb6.0 claro esta
porque como dices en .net debes usar los tableadapter que no me gustan mucho
pero
bueno.

On Fri, 9 Dec 2005 17:34:35 -0500, "rafael"
wrote:

Bueno alfredo hasta ahora no he visto plasmado la forma en que envias los
datos a la bd.

Con "DataBindings".

Pero yo me estoy creando mis propias bibliotecas de clases para poder
prescindir de System.Data y trabajar siempre conectado entre otras
cosas.

o como?
en vb6.0 claro esta

Pues de una forma bastante parecida a vb6 y sobre todo a Delphi.

Se enlazan unos controles visuales a un objeto (que no clase) que
represente a una tabla y listo. El único código que hay que escribir
en la aplicación es para implementar reglas de presentación que no se
puedan implementar de otra manera. De asegurar las reglas de negocio
se encarga el SGBD, y de su implementación el DBA.

porque como dices en .net debes usar los tableadapter que no me gustan mucho
pero
bueno.

A mi tampoco me entusiasman, pero no conozco nada mejor para Visual
Studio.

Pero lo que está claro es que los TableAdapters son mucho mejores que
andar creando clases para cada tabla, consulta y vista, y luego meter
los objetos de esas clases en colecciones.


Saludos

Con "DataBindings".

Esa forma consumen recursos porque requiere estar conectado

Pero yo me estoy creando mis propias bibliotecas de clases para poder
prescindir de System.Data y trabajar siempre conectado entre otras
cosas.

Pero si lo que se busca es estar desconectado?

Se enlazan unos controles visuales a un objeto (que no clase) que
represente a una tabla y listo. El único código que hay que escribir
en la aplicación es para implementar reglas de presentación que no se
puedan implementar de otra manera. De asegurar las reglas de negocio
se encarga el SGBD, y de su implementación el DBA.

Ya ves como no me equivoque eres DBA.
! A el muchachos, a la hoguera !!!, mentira una bromita espero no lo tomes a
mal. :)

>porque como dices en .net debes usar los tableadapter que no me gustan

mucho

>pero
>bueno.
A mi tampoco me entusiasman, pero no conozco nada mejor para Visual
Studio.

En .net porque en 6.0 no existen.

Pero lo que está claro es que los TableAdapters son mucho mejores que
andar creando clases para cada tabla, consulta y vista, y luego meter
los objetos de esas clases en colecciones.

Apoyo en cierta manera tu punto de vista, pero voy a hacer algunas
aclaraciones
no hay duda que crear varias clases que funcionen como el table adapter es
algo
en cierta forma derrochadora de tiempo, pero en vb6.0 es una forma rapida de
hacerlo, otra idea podria hacer como en un ejemplo de .net , crear una clase
que manipule los datos, es decir las inserciones, los store procedures, hay
un codigo
que sale en universidad .net pero el problema es que usa ciertas
caracteristicas de .net
que no las encuentro en vb6.0 , por ejemplo perdona mi ignorancia, pero la
clase
del ejemplo recupera los argumentos del store procedure, y los adapta
deacuerdo al
store procedure que envies, en verdad estuvo complicado en hacer algo
similar al 6.0
no digo que no se puede pero consume tiempo, aunque me gustaria hacerlo
porque
asi no tendria como tu dices, una clase para manejar las operaciones de cada
tabla.
Lo de las entidades de negocio, o clases que son iguales a las entidades del
modelo de datos
son a mi parece utiles, porque puedes luego utilizarlas en otro proyecto ,
puede ser para una
pagina web, etc sin tener que hacer mucho cambio al codigo.

Saludos