datamodule

[josi]

hola a todos

quisiersa saber como se trabaja con data module osea
que en cada form solo tenga que colocar el adoquery sin tener que por cada adoquery colocar un adoconecction.

gracias.....

[[egostar]]

Empezado por josi

hola a todos

quisiersa saber como se trabaja con data module osea
que en cada form solo tenga que colocar el adoquery sin tener que por cada adoquery colocar un adoconecction.

gracias.....

Hola

En el datamodule colocas un solo adoconnection y tantos adoqueries y/o adotables que uses para tus formas.

Salud OS

[*Caro*]

Hola josi, un dataModule te sirve para tener dentro de el, componentes no visuales, que serían los componentes de acceso a datos (AdoConnection, AdoQuery...), solo necesitas un AdoConnection como te dice Egostar y todos los Adoquerys, AdoTables que necesites, en los formularios es suficiente que incluyas el DataModule en el uses, para que puedas acceder a todos tus Querys...., y enlazarlos a tus componentes de bases de datos (dbGrid,dbEdit....).

Saluditos

[roman]

Empezado por Caro

un dataModule [...] solo necesitas un AdoConnection como te dice Egostar y todos los Adoquerys, AdoTables que necesites, en los formularios es suficiente que incluyas el DataModule en el uses, para que puedas acceder a todos tus Querys...., y enlazarlos a tus componentes de bases de datos (dbGrid,dbEdit....).

¿Y los datasource, donde van?

// Saludos

[[egostar]]

Empezado por roman

¿Y los datasource, donde van?

// Saludos

Buena pregunta , yo los pongo en el mismo datamodule, que te parece, está mal ?

Salud OS

[[Caral]]

Hola
Para mi en esto no hay una regla establecida, ni tampoco una linea a seguir, depende de la comodidad de cada uno.
En mi caso en el Datamodule solo pongo el conector (AdoConnection) por que??, por que es el que ligara a todos en el programa.
En cada form pongo lo que necesito, tanto los adotable, adoquery, datasource, por que???, por que es mas facil revisar el código que conecta cada uno, sin tener Sopotocientos en el datamodule y dandoles nombres descriptivos para no equivocarte, abriendo cada dos por tres el datamodule para verificar.
Se que lo correcto seria todo en el Datamodule, para eso es, pero la comodidad es muy subjetiva.
Saludos

[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.

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.

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

[[Caral]]

Hola
Para mi hay algo que aveces perdemos de vista, quien hace la pregunta?.
Cuando empece ya hace casi dos años en esto de la programación, os leía y por supuesto no entendía nada, hice preguntas que seguramente para vosotros fueron muy básicas e incluso ingenuas.
Coincido, después de estos años, que lo que planteas es lo mejor, es lo adecuado y que de alguna manera ordena el formulario, pero pregunto:
Cuando se empieza en esto no es mas fácil poner los componentes en el mismo formulario, que ademas, muy seguramente por el tamaño de la aplicación, ya que estoy empezando, serán pocos?.
Se que el que mal aprende, mal programara al final, por eso creo que indicar la mejor manera es correcto, pero también incluir la facilidad para entender el concepto lo es, o no?.
Siempre es un placer y un privilegio leerte Maestro Roman.
Saludos

[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

[*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

[josi]

gracias a ustedes por su ayuda.

tengo otro problema tengo el datamodule con el adoconecction
y un form con un adotable, en objec inspector en la propiedad conecction lo conecte con 'DataModule3.ADOConnection1' y en el modo de edicion las tablas se me conectan bien e incluso tiro los campos en el form pero cuando ejecuto
me sale este error que dice: proyect proyect1.exe raisedwxception class EDATABESEError with message 'missing Conection or conection string'.

gracias.......

[[Caral]]

Hola
Tienes que hacer la conexion de la tabla al adoconnetion, osea, en diseño lo haces por las pantallas y se conecta bien, en ejecucion, buscara la conexión y la tabla.
Como conectas el adoConnection??.
Saludos

[[egostar]]

Pues dadas las letras de roman, sería muy interesante hacer un hilo donde podamos obtener a través de las experiencias de compañeros la forma digamos más adecuada de usar estos componentes, realmente es muy interesante lo que dices amigo roman y creo que tus comentarios tienen mucho peso en la comunidad y personalmente hago de tus comentarios una verdad

Salud OS

PD. Por favor olvida lo de XPMan

[josi]

bueno me voy al object inspector del adoconnection y luego en la propiedad connection string me sale la ventanita me voy a build me sale en vinculo de datos y elgijo la base de datos la pruebo y le doy aceptar, y la activo.

[[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,

[[Caral]]

Hola
Pregunto: Que base de datos usas?.
Saludos

[josi]

estoy usando access

[[Caral]]

Hola
En esta pagina del wiki hay varios ejemplos de como hacer la conexion, este en especial es muy básico.
Saludos

[roman]

Empezado por Delphius

Ese primitivo mecanismo de observación vendría a ser el uso del patrón Observador?

Pues algo así. Pero ése es el problema. La VCL implementa este patrón precisamente en la conexión DataSet<--DataSources y DataSource<--DataLinks, así que suena demasiado tener que hacerlo otra vez para sincronizar la interfaz con el acceso a datos. Por ello es que la solución de Al me parece muy adecuada.

Por otra parte;

Empezado por Caro

pero ahora leyendo tu explicación me parece mejor que este en el formulario, de ahora en adelante asi lo hare

Empezado por egostar

y creo que tus comentarios tienen mucho peso en la comunidad y personalmente hago de tus comentarios una verdad

Yo quisiera que esto no fuera así amigos. Porque aquí hay gente con mucha más experiencia que yo y mi opinión no necesariamente refleja lo más adecuado. Aquí, por ejemplo, yo pregunto, porque me parece raro que la VCL maneje así las cosas siendo que se supone que los datamodules están ahí precisamente para separar la interfaz del acceso de datos. Entonces pienso: quizá yo no estoy entendiendo bien y quiero ver cómo hacen los demás. Pero es eso, una pregunta, y no la verdad de cómo deben hacerse las cosas.

Espero que no se tomen a mal esto, desde luego que es halagador que la gente piense que la opinión de uno tiene peso, pero el tener muchos posts, no es lo mismo que tener mucha experiencia.

// Saludos

[[Delphius]]

Empezado por roman

Pues algo así. Pero ése es el problema. La VCL implementa este patrón precisamente en la conexión DataSet<--DataSources y DataSource<--DataLinks, así que suena demasiado tener que hacerlo otra vez para sincronizar la interfaz con el acceso a datos. Por ello es que la solución de Al me parece muy adecuada.

Por eso mismo mis ideas pasan por emplearlo. Si el patrón Observador me garantiza esa "sincronización" ¿Porqué no usarlo?

Es cierto que aplicarlo tiene sus desventajas... y si no empleamos objetos data-ware... ¡ni que hablar! Que ya he visto varios hilos en donde se expone el tema.

Son distintas soluciones, y alternativas. En fin, me parece que buscarle un solo punto de vista que sea productivo y que nos solucione todos los problemas es algo muy dificil de conseguir.

Empezado por roman

Por otra parte;

Yo quisiera que esto no fuera así amigos. Porque aquí hay gente con mucha más experiencia que yo y mi opinión no necesariamente refleja lo más adecuado. Aquí, por ejemplo, yo pregunto, porque me parece raro que la VCL maneje así las cosas siendo que se supone que los datamodules están ahí precisamente para separar la interfaz del acceso de datos. Entonces pienso: quizá yo no estoy entendiendo bien y quiero ver cómo hacen los demás. Pero es eso, una pregunta, y no la verdad de cómo deben hacerse las cosas.

Yo no soy quien para decir si lo dicho por ti y otros es lo más adecuado, pero reconozco que tus palabras son a tener en cuenta.

A mi me parece que los motivos de los ingenieros de codegear para estructurar asi la VCL fue certero. Y como toda decisión implica llevar sus pros y contras.

Se separa amigo, y como sabemos... no se puede evitar la relación. Si podemos estructurar el trabajo de tal forma que se reduzca la dependencias y relación entre estas dos capas.

En lo personal, me encantaría decirte que yo trabajo de x forma. Pero como he dicho antes... todavía estoy analizando este tema. Y por el momento, no tengo una inclinación de uno sobre otros. Si puedo decir que se que parte de ello se debe a mi manera casi "purista" de verlo bajo el microscopio de POO. El tener una postura demasiada pura en este asunto me nubla y me impide decir: "Este diseño soluciona todos mis problemas".

La cuestión está en encontrar un punto de vista que nos resulte cómodo. Y para mi, por el momento el punto de vista cómodo pasa por analizar caso por caso (proyecto por proyecto) en vez de imponer un diseño único a todos mis desarrollos (mejor dicho... futuros desarrollos) e ideas.
Esto no quita que tenga en mente la idea de reutilización, y otros conceptos y buenas prácticas. Entre ellas el diseño de bibliotecas de propósito general, alguna especie de "framework", y demás cosas que asisten y facilitan el trabajo.

Lo que digo es que a mi modo de ver, el diseño de la arquitectura prefiero analizarlo desde el punto de vista de los requisitos, restricciones de proyecto, planes a futuro... en definitiva en base al ambiente o negocio.

Si mis análisis me demuestran que el sistema no va a ser demasiado volátil, y no requiere demasiada indepedencia entre las capas (una capa de negocio delgada tal vez) un diseño rápido es lo más útil y puede que tener todo en un datamodule basta y sobre.

Pero si hay probabilidades de que el sistema fluctue, se amplie, se cambien el motor, y el ambiente demuestra una gran complejidad en sus operaciones, prefiero una alternativa dirjida hacia garantizar lo máximo posible la independencia de cada capa. Y esto me llevará a analizar que es mejor:
1. la eterna pregunta ¿usar data-ware?
2. Un diseño asistido por observadores
3. Un diseño orientado como la descripción de roman
4. Un diseño como el que menciona roman, y la alternativa de Al
5. etc...
6. ¿Una mezcla de éstas?

Empezado por roman

Espero que no se tomen a mal esto, desde luego que es halagador que la gente piense que la opinión de uno tiene peso, pero el tener muchos posts, no es lo mismo que tener mucha experiencia.

// Saludos

Yo no tengo demasiada experiencia. Y por ello mucho no puedo decir.

Saludos,