DESARROLLO EN 3 CAPAS

Hola Cristian,

On Thu, 24 Nov 2005 14:19:31 -0300, "Cristian Ledesma"
wrote:

yo he trabajado en Win32 exactamente como tu
describes, todo el negocio en la Base de datos, por varios motivos unos de
ellos es que al cambiar una regla solo modifico en la BD y luego ya esta
todas las aplicaciones que acceden a la BD ya no es necerario tocar nada,

Pues eres un privilegiado.

ahora mi problema es que realmente eso seria 2 capas, la del usuario y la de
la Base de datos(Bussines + SP's) lo cual no es complejo de mantener, pero
he visto en ejemplos del .net princiapalmente en VS2003 que todos o casi
todos implementan el uso de Clases de persistencia(objetos)

Es que los que escriben esos ejemplos no tienen ni idea, y en muchos
casos escriben de oidas y nunca han probado a hacer eso en un proyecto
grande.

en ves de
DataSet's que seria lo ideal pues el DataSet ya trae consigo los eventos
donde se puede validar mejor ademas de trabajar desconectado etc, en tu
opinion para una aplicacion Winforms cual seria la forma correcta de
implementar esto.

Pues para trabajar desconectado del SGBD central lo mejor es trabajar
conectado a un SGBD local. Es decir que lo mejor es instalar un SGBD
en cada máquina cliente, mantenerlo sincronizado y trabajar siempre
conectado a él. Algo parecido a lo que se hace con las aplicaciones
para Pocket PC que usan SQL Server CE.

Con los nuevos TableAdapter de VS 2005 esto es más fácil, aunque
ADO.NET 2.0 sigue dejando mucho que desear.

1. - Generar Clases para la Persistencia y esta persistencia es la que hace
el Binding correspondiente.

Esto no, por que es un trabajo innecesario y además la mayoría de la
gente que hace esto lo hace para asegurar la lógica de negocio en las
aplicaciones lo que va en contra de lo que te enseñan en la primera
clase de cualquier curso de bases de datos.

2.- Trabajar directamente el DataSet' para Persistir los datos y de alli
directamene a la BD.

Lo mejor es usar los DataSet, o crearnos nosotros unas clases mejores
simplemente para ayudar a presentar los datos a los usuarios y
mandando las actualizaciones inmediatamente al SGBD (local o remoto)
para que las valide. Así nos ahorramos el tener que asegurar las
reglas de negocio dos veces.


Saludos
Alfredo

Bueno amigo christian, yo empleo clases para poder hacer mas facil el
mantenimiento, te pongo un ejemplo
Clase EntidadPersona
Public nombre as string
public apellido as string
public direccion as string

clase DatosPersona
Public function Grabar (nuevaPersona as entidadPersona) as boolean
'codigo que inserta el nuevo registro en la tabla persona
end function

Parece algo innecesario de codigo, pero normalmente puede ocurrir que se
añada o elimine algun atributo, si esto sucediera cambia la llamada al
procedimiento?
NO
porque como lo que envias es una clase.
Otro beneficio es el de no tener que escribir procedimientos con gran numero
de argumentos.
Ejemplo de funcion con gran numero de argumentos
Public function Grabar(Nombre as string,Apellido as string,Direccion as
string,Dni as string,Telefono as string,Sexo as string,FechaNacimiento as
date,etc...) 'el etc en este caso significa n campos adicionales

Al actualizar la aplicacion o modificar se sufre menos.
Sobre las reglas de negocio , las sigo incluyendo en el SGBD, a mi criterio
por cuestiones de integridad y velocidad y facilitar el mantenimiento. Por
ejemplo los valores unicos como el DNI, son obviamente candidatos para
indices o claves alternas,la restriccion del rango de valores.

sino que como tu has mencionado, hay ejemplos de vs.net y mencionan la
programacion de componentes, en 3 capas, pero en los ejemplos siempre
aparece el caso tipico del componente de negocio que maneja la transaccion,
creo que es la clasica de la orden y el detalle del pedido. Esa clase la
implementa como de logica de negocio, pero eso suscita algunas dudas que
tambien le manifeste a Alfredo, Como si esa clase deberia incluir tambien
los procedimientos listar o eliminar, porque si solo tuviera un
procedimiento, no tiene mucho chiste hacer una clase para ello.

Hola,

On Thu, 24 Nov 2005 14:19:31 -0300, "Cristian Ledesma"
wrote:

1. - Generar Clases para la Persistencia y esta persistencia es la que hace
el Binding correspondiente.

¿Podrías explicar un poco que quiere decir esto?

Por que así escrito pone bastante los pelos de punta :)


Saludos
Alfredo

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, 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.
2.- No puedo Saber el Status del Registro (Si ha sufrido Cambios etc).
3.- Es como reinventar la rueda ,puesto a que el DataSet ya es una clase.
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.
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

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

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, es mas
yo por ejemplo hago lo Sgte, tomo un Registro con esos 3 campos sitados
Arriba si el Campo Nombre es el unico que ha cambiado en ese
Registro(DataRow)
entonces Genero un SQL que me actualize solo ese campo para evitar enviar
todo de nuevo contra la base de datos.

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, muchos me an dicho que es pq quieren trabajar
desconectados pero yo creo y afirmo que el DataSet ya trabaja desconectado,
para terminar no me imagino lo que seria hacer un Reporte con la
Persistencia de este tipo en Clases.

Atte. Cristian Ledesma


"Alfredo Novoa" escribió en el mensaje
news:

Hola,

On Thu, 24 Nov 2005 14:19:31 -0300, "Cristian Ledesma"
wrote:

1. - Generar Clases para la Persistencia y esta persistencia es la que
hace
el Binding correspondiente.

¿Podrías explicar un poco que quiere decir esto?

Por que así escrito pone bastante los pelos de punta :)


Saludos
Alfredo

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