17 respuestas en este tema

[look]

Hola, me gustaria saber:
¿que son los DM?
¿cual es su mejor aplicacion?
he estado viendo que es una especie de formulario en donde se ponen los objetos de las base de datos y tablas, no me queda muy claro porque, cual es el beneficio o la forma en que estos trabajan.
saludos.

[egostar]

Hola

Use a TDataModule object in an application to provide a location for centralized handling of nonvisual components. Typically these are data access components, such as TSQLDataSet, and TSQLConnection. DataModules are not limited to data access components, they can also contain other nonvisual components, such as TTimer, TOpenDialog, or TImageList).

Utilice un objeto TDataModule en una aplicación para proporcionar una ubicación para el manejo centralizado de los componentes no visuales. Generalmente, estos son componentes de acceso a datos, tales como TSQLDataSet y TSQLConnection. DataModules no se limitan a los componentes de acceso a datos, también pueden contener otros componentes no visuales, como TTimer, TOpenDialog o TImageList).

Salud OS

[look]

Hola

Use a TDataModule object in an application to provide a location for centralized handling of nonvisual components. Typically these are data access components, such as TSQLDataSet, and TSQLConnection. DataModules are not limited to data access components, they can also contain other nonvisual components, such as TTimer, TOpenDialog, or TImageList).

Utilice un objeto TDataModule en una aplicación para proporcionar una ubicación para el manejo centralizado de los componentes no visuales. Generalmente, estos son componentes de acceso a datos, tales como TSQLDataSet y TSQLConnection. DataModules no se limitan a los componentes de acceso a datos, también pueden contener otros componentes no visuales, como TTimer, TOpenDialog o TImageList).

Salud OS

entiendo. me igmagine que de este modo trabajaban, hasta ahora siempre he dejado los componentes no visuales en los formularios, los voy utilizando a medida que los necesite.
bueno le voy a hechar un vistado pero no me llama mucho la atencion la utilidad de este concepto, como sea ¿ es mejor utilarlos?

[egostar]

entiendo. me igmagine que de este modo trabajaban, hasta ahora siempre he dejado los componentes no visuales en los formularios, los voy utilizando a medida que los necesite.
bueno le voy a hechar un vistado pero no me llama mucho la atencion la utilidad de este concepto, como sea ¿ es mejor utilarlos?

Lo único que te puedo decir es que centralizar el acceso a datos es una buena práctica, personalmente no desarrollo un sistema sin este objeto, pero como todo, es cuestión de estilos de programación.

Salud OS

[felipe]

Hola

Use a TDataModule object in an application to provide a location for centralized handling of nonvisual components. Typically these are data access components, such as TSQLDataSet, and TSQLConnection. DataModules are not limited to data access components, they can also contain other nonvisual components, such as TTimer, TOpenDialog, or TImageList).

Utilice un objeto TDataModule en una aplicación para proporcionar una ubicación para el manejo centralizado de los componentes no visuales. Generalmente, estos son componentes de acceso a datos, tales como TSQLDataSet y TSQLConnection. DataModules no se limitan a los componentes de acceso a datos, también pueden contener otros componentes no visuales, como TTimer, TOpenDialog o TImageList).

Salud OS

entiendo. me igmagine que de este modo trabajaban, hasta ahora siempre he dejado los componentes no visuales en los formularios, los voy utilizando a medida que los necesite.
bueno le voy a hechar un vistado pero no me llama mucho la atencion la utilidad de este concepto, como sea ¿ es mejor utilarlos?

Debería llamarte la atención, más si tus aplicaciones trabajan con acceso a datos.

Saludos!

[look]

entiendo, bueno hasta ahora no he tenido problemas con mi manera de trabajar sin DM, voy hacer unas pruebas.
gracias por sus comentarios.

[felipe]

entiendo, bueno hasta ahora no he tenido problemas con mi manera de trabajar sin DM, voy hacer unas pruebas.
gracias por sus comentarios.

Puede que no, pero seguramente notarás cambios en el rendimiento. Ya nos comentarás como te fué


Saludos!

[look]

entiendo, bueno hasta ahora no he tenido problemas con mi manera de trabajar sin DM, voy hacer unas pruebas.
gracias por sus comentarios.

Puede que no, pero seguramente notarás cambios en el rendimiento. Ya nos comentarás como te fué


Saludos!

seguro que si, gracias nuevamente.

[Caral]

Hola
Bueno:
El datamodule:
Un lugar en el espacio:

Después de este preámbulo, yo opino..........
No es muy bueno para contener todos los componentes no visuales de conexion a las BD.
Esto lo digo por que:
Si se tiene una aplicacion de muchos forms revisar los codigos se hace mucho mas sencillo cuando los componentes estan en el mismo form.
Ahora:
Lo que si se puede colocar en el DM son los tables ya que nunca cambia su contenido.
Por lo tanto:
Aunque se diga que el DM es especial para contener estos no siempre sera la mejor opcion.
Insistiendo:
Si se colocan querys en el DM se hara un arroz con mango (dicho Tico), que no sabra bien.
Incluso:
Se comenta que mejora la velocidad, Bueno, seria imperceptible.

No se, digo.......
Saludos

[Delphius]

Creo que lo dicho en otro hilo también podría llevar a comprender el tema.

Saludos,

[Rolphy Reyes]

Saludos.

"Sin DataModule no existen aplicaciones con conexión a Base de Datos".

Procedo a explicar porque. En mis desarrollos personales tengo un DataModule que contiene los componentes de conexión a la BD (Connection, Transaction, etc...).

Luego tengo un DataModule base donde colocó un TDataSet y tiene un constructor para pasarle el DataModule de conexión a la BD; además de una series de métodos públicos que encapsulan las distintas llamadas a Insert, Update, Delete, Cancel y Post.

Ahora bien el detalle esta en que cada tabla de la BD tiene su DataModule, donde cada DataModule tiene lo necesario para "hablar" con esa tabla en particular.  Gano con esto, que donde necesite trabajar con una tabla solo agrego esa unidad que sabe lo que tiene que hacer. Desventaja que puede ser un tanto incómodo para darle mantenimiento.

Mis formularios tienen un TDataSource y una propiedad tipo DataModule Base, donde ellos instancian el DataModule que necesiten.

Espero que se comprenda.

[egostar]

Insisto en que sigue siendo cuestion de gustos y estilos

Tu estilo me gusta amigo Rolphy

Salud OS

[cadetill]

Buenas,

Yo estoy de acuerdo con egostar, todo es cuestión de gustos.

Personalmente me gusta diferenciar la gestión de los datos de lo que es la parte visual, pero entiendo y comprendo a la gente que le gusta tener ese control dentro del mismo formulario. Además, es cierto que la programación con DM se complica si haces herencia visual y usas aplicaciones MDI.

No obstante, si yo tuviera que escoger, sin duda diría que programar con DM es una buena práctica

Nos leemos

[Rolphy Reyes]

Buenas,

Yo estoy de acuerdo con egostar, todo es cuestión de gustos.

Personalmente me gusta diferenciar la gestión de los datos de lo que es la parte visual, pero entiendo y comprendo a la gente que le gusta tener ese control dentro del mismo formulario. Además, es cierto que la programación con DM se complica si haces herencia visual y usas aplicaciones MDI.

No obstante, si yo tuviera que escoger, sin duda diría que programar con DM es una buena práctica

Nos leemos

Saludos.

Justamente por ser MDI las aplicaciones por eso empleo ese modelo que describí en el mensaje anterior.  Con eso de que cada Formulario instancia su DM me evito el problema de que la data sea "compartida" y se refleje los movimientos dentro del TDataSet en los distintos formularios.

[cadetill]

Buenas

....Con eso de que cada Formulario instancia su DM me evito el problema de que la data sea "compartida" y se refleje los movimientos dentro del TDataSet en los distintos formularios.

Efectivamente, ese es uno de los problemas al programar con MDI. Yo hago lo mismo, instancio un DM por cada child creado. Esto hace que en cada child creado se tenga que asignar el DataSource por código para que los componentes apunten "al que toca" o si tienes los DataSources en el child, hacer apuntar a éstos a los DataSets que toquen

Nos leemos

[look]

ahora entiendo mas a profundidad, bueno mi inquietud venia mas porque a mi me gusta trabajar con forms MDI, es aqui donde se complica la situacion, de alli venia mi duda, pero ahora tengo mas claro el panorama.
saludos

[egostar]

ahora entiendo mas a profundidad, bueno mi inquietud venia mas porque a mi me gusta trabajar con forms MDI, es aqui donde se complica la situacion, de alli venia mi duda, pero ahora tengo mas claro el panorama.
saludos

Y yo ahora entiendo con mas claridad tu cuestionamiento , que bueno que tenemos diferente estilo de programar ya que de esa forma conocemos los pros y contras de cada uno y en consecuencia adoptar otro, corregir o continuar con el propio .

Salud OS

[Delphius]

De todas formas es como dice Eliseo, cuestión de "gustos" y de una serie de DEPENDES. 

En resumen, no hay mejor o peor... Cada uno de los diseños y alternativas tienen sus pros y contras y queda en uno en determinar cual (o combinación de éstas, incluso) es la que mejor se ajusta a las necesidades.

En algunos proyectos será viable la alternativa A, para otros la Z.

Todo pasa por saber determinar aquellos puntos de unión y determinar como poder garantizar que estos puntos son lo suficiente estables. Hay una frase que dice algo así como que la parte más fuerte de la cadena está en la unión más débil. Una vez que se destruye esta todo se cae a pedazos.
En el desarrollo de un sistema pasa algo similar. La fortaleza de nuestros sistemas estará medida por la dureza de las uniones de los módulos.

Si haces de A puede que te falte algo que tenga B, y a la inversa... si vas por B algo te faltará que tiene A.

La unión de los módulos obedece a dos principios que no se pueden tratar de forma separada: acoplamiento y cohesión. Intenten atacar a uno sin afectar al otro 

Saludos,