datamodule

[*Caro*]

Hola Roman, yo pongo los DataSource en el DataModule, pero ahora leyendo tu explicación me parece mejor que este en el formulario, de ahora en adelante asi lo hare .

Saluditos

[[Delphius]]

Empezado por roman

Es cierto que cada quien se acomoda de una u otra forma, pero creo que mezclar los DataSet en el formulario, a la larga resulta muy complicado. Yo lo hacía así, pero terminas teniendo demasiado código revuelto.

Muchas veces, en el formulario hay que poner código que sólo tiene que ver con la interfaz de usuario, como habilitar o inhabilitar controles, responder a eventos del teclado o del ratón, etc. Si además mezclamos el código de validación de datos, inicialización de registros, etc., el formulario puede convertirse en una mezcla muy difícil de leer.

Es muy cierto, y yo trato de seguir esa misma regla. Cada cosa en su lugar.

Empezado por roman

Yo trato de colocar todos los DataSet en su correspondiente datamodule, y los datasource en los formularios. La razón es que me parece que se crea mejor independencia entre los formularios y los datamodule. Si quiero cambiar de componentes de acceso a datos, en principio sólo tengo que apuntar el datasource del formulario al nuevo componente, mientras que si dejo el datasource en el datamodule, tendría que redireccionar todos los componentes db aware al nuevo datasource (porque al cambiar de componentes estoy pensando en un nuevo datamodule).

No obstante, el datasource es muy poca cosa, y aunque no sé si es la razón exacta, creo que es por ello que Al González trabaja con un derivado del TDataSource que repite los eventos del dataset.

Vamos a ver. Creo que siempre es mejor mantener separado el código de interfaz de usuario del código de acceso a datos; es más legible. Pero simplemente poniendo los dataset en un datamodule y los componentes dbaware en l formulario, no es suficiente: ¿qué pasa si necesitamos actualizar elementos de la interfaz de usuario conforme nos movemos por los registros? Necesitaríamos el evento AfterScroll, pero resulta que está en el DataModule. ¿Qué pasa si hay un error en la inserción de un registro? Para avisar al usuario necesitamos el evento OnPostError del dataset, pero está en el datamodule. Etc.

En algunos casos es suficiente con el evento OnDataChange del datasource, pero este evento se genera por muchas causas así que no siempre es lo suficientemente fino.

Esa arquitectura suena muy viable amigo. Y como mencionas y das a entender, cada diseño que optemos tiene sus ventajas y desventajas.

Empezado por roman

En algunas ocasiones lo que he hecho es implementar un mecanismo primitivo de observación (esto a Delphius le encanta poniendo en el datamodule una propiedad "formulario" que apunta al formualrio (o una lista de formularios) a los que hay que avisar acerca de algún evento. Pero, creo que la solución que da Al es a la larga mucho más clara y práctica.

En fin, para opinar...

// Saludos

¿Cómo supiste que eso me gusta ? Ese primitivo mecanismo de observación vendría a ser el uso del patrón Observador?

Yo todavía, en este aspecto no tengo totalmente decidido como desarrollar la arquitectura del sistema. Puesto que cada vez que me planteo encarar la arquitectura encuentro puntos débiles y otros fuertes.

Y eso es lo que a mi me resulta interesante. Creo que a la larga los requerimientos y algunas restricciones tanto del proyecto como del sistema terminan conduciendonos a la alternativa que nos ofrezca las mayores ventajas posibles.

Y para conseguir esto se necesita de muchas pruebas, de práctica. Cuestiones de ensayo y error nos conducirán a que con el tiempo se forme y se entrene a determinar cual diseño conduce a mayores ventajas.

Empezado por roman

Algo que se me olvidó en el mensaje anterior:

Los datasource que sí coloco en el datamodule, son los que uso para relaciones maestro-detalle. Por ejemplo, si en el datamodule tenemos un TdsFactura y un TdsLineasFactura, tendré un datasource en el datamodue que apunte a TdsFactura para hacerlo maestro de TdsLineasFactura. En el formulario tendré otro datasource también apuntando a TdsFactura para presentar los datos de la factura.

De cualquier forma, yo hice la pregunta un poco para ver sus opiniones, no para hacer ver que ésa es la forma de hacer las cosas, porque es algo que no termino de aclararme.

// Saludos

Buena idea amigo.

Creo que lo que he dicho en el párrafo anterior apoya y complementa a tu último párrafo.

Si tu dices que no terminas de aclararte... pues que me depara a mi.
No mentira... Para mi no tiene sentido buscar un diseño que nos resuelva todos los problemas. Y es por ello que en estos aspectos, habrá muchas formas de encararlo. Lo cual no es de extrañar que "a diario" nos plantiemos si el diseño elegido es el más adecuado.

Estamos hablando de un aspecto gris dentro del análisis y diseño. El punto de unión entre la capa de datos y la interfaz es una zona que no está totalmente delimitada.
Al menos asi lo veo yo.

Saludos,