Un Datomodulo o varios?

[ContraVeneno]

Pues yo tenía entendi que un módulo de datos sirve para agregar todas las consultas y conexiones en un solo lugar y no tener que andar buscando cuál es la consulta que necesitas en todo el proyecto... así que siguiendo mis pocos conocimiento en el tema, no me parece lógico tener dos o más módulos de datos...

Se supone que en el módulo se debe agrupar todo lo que requieras, no le veo sentido a tener dos agrupaciones de algo que puedes agrupar en un solo lugar.

Esa es mi humilde opinión.

[zcatzz]

Muchas gracias por sus opiniones Caral y Contraveneno , quiere decir que no andaba tan errada, ahora lo que voy a hacer es ir poniendolo lo mas ordenadamente posible para que cuando lo vea la analista no se espante jeje ... y siguiendo con el tema alguien sabe si es correcto mi idea de que donde dice diagramas es solo para documentar.. o si me pongo a hacer cosas ahi al rato se alente el programa por estar haciendo diagramas explicativos

[[Caral]]

Hola
Y donde dice diagramas?
En que parte?
Saludos

[zcatzz]

Empezado por Caral

Hola
Y donde dice diagramas?
En que parte?
Saludos

Ya vez que la ventana del datamodulo esta compuesta por 2 partes, en la parte derecha te muestra los iconos de los objetos que estes agregando (adoquerys,etc) en una pestaña que dice components , son 2 pestañas la otra dice data diagram y en ese es donde quisiera saber para que sirve

[[Caral]]

Hola
La verdad lo busco y lo busco y no lo encuentro, si no lo tengo seguro nunca lo he usado, no debe hacer mayor cosa.
Si es un asunto para hacer un diagrama de uso no debe afectar en nada al programa, usalo si te sirve.
Que delphi usas?, yo uso delphi6
Saludos

[roman]

Empezado por ContraVeneno

Pues yo tenía entendi que un módulo de datos sirve para agregar todas las consultas y conexiones en un solo lugar y no tener que andar buscando cuál es la consulta que necesitas en todo el proyecto... así que siguiendo mis pocos conocimiento en el tema, no me parece lógico tener dos o más módulos de datos...

Se supone que en el módulo se debe agrupar todo lo que requieras, no le veo sentido a tener dos agrupaciones de algo que puedes agrupar en un solo lugar.

Quizá la centralización que mencionas no esté peleada con la separación de módulos. Digamos que tu empresa es muy compleja y cada área es un mundo aparte. Quizá tengas por un lado, todo lo relacionado con el personal, por otro lado , lo relacionado con las ventas y por otro lo relacionado con los productores.

Cuando tengas que hacer un cambio en las reglas de ventas, tendrás que buscar en las decenas de datasets de tu único módulo, entre componentes que no tienen ninguna o muy poca relación con lo que buscas.

¿No sería mejor y más claro, organizar el proyecto de manera de separar las distintas áreas en módulos diferentes? El datamodule de ventas sigue centralizando el acceso a datos, en un sólo lugar y, sabes bien en qué parte debes buscar para hacer modificaciones relacionadas con el área de ventas.

Es decir, el clóset te sirve para tener toda tu ropa en un sólo lugar en lugar de tenerla regada por toda la habitación. Pero no por ello vas a meter los calzones, las camisas y los pantalones en un sólo cajón.

Empezado por Caral

En el caso de dos o mas datamodules no se como trabajaria la conexion ya que tienes que estar nombrandolos en el uses, no se a mi se ma hace mas coplicado.

Podrías tener un datamodule central, donde colocas la conexión y quizá tablas sencillas, como catálogos, que se usan en muchas partes de la aplicación y deben estar siempre disponibles. Y luego, un datamodule por cada área específica de la aplicación. Cada uno de éstos tendrá, desde luego, que incluir al principal.

// Saludos

[marcoszorrilla]

Estoy de acuerdo con Román. Yo siempre utilizo varios Módulos de Datos. Por ejemplo:
Todos los accesos a Datos de contabilidad: DmConta.
Todos los accesos a Terminales por internet:DmTerm.
Y así sucesivamente.

Esto me permite que dichos Módulos de Datos estén cerrados y solamente se creen si alguien hace uso de los datos que en ellos se encuentran. Cuando se abandonan dichos datos los Módulos de Datos se destruyen.

La conexión a la base de datos, TSession(según los casos), estarán en el módulo principal que siempre lo tengo abierto.

Un Saludo.

[[Lepe]]

Caral, hasta delphi 7 la ventana de código tiene 2 pestañas abajo, code y diagram. En diagram, se puede arrastrar por ejemplo un botón, un TTable, etc y hacer un esquema de las relaciones de los componentes.

Alguna vez hice un diagrama y pasados unos meses delphi se lo comió con patatas, suerte que lo salvé como wmf, pero aún así me fastidió bien. No lo volví a usar.


En cuanto a los modulos de datos, yo también soy partidario de varios de ellos, como mínimo 2: dmConection y dmPrint. No tiene sentido mezclar las consultas hechas para imprimir con el resto de los datasets.

Normalmente en la interfaz usamos un DBLookUpcombo para mostrar un dato de otra tabla, sin embargo al imprimir tenemos que unir ambas tablas para mostrar los datos de otra forma.

Saludos

[ContraVeneno]

Empezado por roman

Es decir, el clóset te sirve para tener toda tu ropa en un sólo lugar en lugar de tenerla regada por toda la habitación. Pero no por ello vas a meter los calzones, las camisas y los pantalones en un sólo cajón.

Jojojo, con ejemplos tan gráficos y específicos, no hay manera de debatir,

Empezado por roman

Podrías tener un datamodule central, donde colocas la conexión y quizá tablas sencillas, como catálogos, que se usan en muchas partes de la aplicación y deben estar siempre disponibles. Y luego, un datamodule por cada área específica de la aplicación. Cada uno de éstos tendrá, desde luego, que incluir al principal.

Totalmente de acuerdo.

[Casimiro Noteví]

Yo también creo multitud de 'DataModule', me gusta tener todo ordenadito, mi lema es: 'Un lugar para cada cosa, y cada cosa en su lugar'

He aquí una lista de los que hay en el proyecto donde trabajo habitualmente:

DMBusqArticulosPrecios, DMBusqDocumentos, DMBusqEfectos, DMBusqMaquinas, DMBusqPersonal, DMBusqProCli, DMBusquedas, DMConsultas, DMAlmacenes, DMAlquileres, DMArticulos, DMBancos, DMCompras, DMConsultasLineas, DMEfectos, DMEscandallos, DMEstadisticas, DMEtiquetas, DMFacturacion, DMInformes, DMPartesTrabajo, DMPersonal, DMPrecios, DMPrincipal, DMProcedimientos, DMProCli, DMProduccion, DMRegistros0, DMRepresentaciones, DMRiesgos, DMSeguridad, DMSeries, DMVentas, DMEstadisiticasClientes, DMEstadisticasArticulos, DMEstadisticasClientes, DMEstadisticasFamilias, DMEstadisticasPersonal, DMEstadisticasProveedores, DMEstadisticasPuestosTrabajo, DMEstadisticasZonas

[zcatzz]

Muchas gracias por sus comentarios .. ya despues de haber leido sus ejemplos y explicaciones, me voy por hacer todo organizado .. Me gusta la idea de Roman de hacer un principal con la conexion y tablas general y cada seccion separarla por paquetes...

Gracias