Hola Estoy escribiendo una aplicación, hay varias formas y sus correspondientes módulos de datos. Escribí de forma que se usan entre sí mencionando en clase de usos (uno en implementación y otro en interfaz para evitar referencias cruzadas) ¿Este enfoque es incorrecto? ¿Por qué o por qué no debería usar de esta manera? GraciasUso de Delphi DataModule: ¿solo o múltiple?
Tengo que estar de acuerdo con Ldsandon, en mi humilde opinión, es mucho mejor tener más de un módulo de datos en su proyecto. Si lo ves como una cosa Model - View - Controller, tu DB es el modelo, tus formularios serían las Vistas y tus módulos de datos serían los controladores.
Personalmente, siempre tengo POR LO MENOS 2 módulos de datos en mi proyecto. Un módulo de datos se usa para compartir acciones, ImageLists, DBConnection, ... y otras cosas a lo largo del proyecto. La mayoría de las veces este es mi principal módulo de datos.
A partir de ahí creo un nuevo módulo de datos para cada 'Entidad' en mi aplicación. Por ejemplo, si mi aplicación necesita procesar o mostrar pedidos, cursomters y productos, entonces tendré un Módulo de datos para cada uno de ellos.
De esta manera puedo separar claramente la funcionalidad y reutilizar fácilmente piezas y piezas sin tener que tirar de todo. Si necesito algo relacionado con los Clientes, simplemente uso el Módulo de Datos del Cliente y solo eso.
Saludos,
Stefaan
Está bien, sobre todo si se va a crear más de una instancia de la misma forma cada uno usando una instancia diferente del módulo de datos relacionada.
Solo tenga en cuenta un pequeño problema en el diseño VCL: si crea dos instancias del mismo formulario y sus módulos de datos, ambos formularios apuntarán al mismo módulo de datos (debido a la forma en que VLC resuelve enlaces) a menos que use un pequeño truco al crear la instancia del módulo de datos:
if FDataModule = nil then
begin
FDataModule := TMyDataModule.Create(Self);
FDataModule.Name := ''; // That will avoid pointing to the same datamodule
end;
+1 por mencionar el truco con el nombre del módulo de datos. –
Beyond the looking glass. Siempre uso Forms en lugar de DataModules. Sé que no es terreno común, lea antes de votar.
Siempre uso Forms en lugar de DataModules. Los llamo DataMovules.
Utilizo uno de estos DataMovule por cada grupo de tablas lógicamente relacionadas.
Uso de formularios en lugar de módulos de datos porque tanto los módulos de datos como los formularios son contenedores de componentes y ambos se pueden usar efectivamente como contenedores para componentes relacionados con los datos.
Durante el desarrollo:
Después del desarrollo:
me vuelvo forma invisible. Prácticamente convirtiéndolo en un DataModule, disfruto de las mismas características de contenedor que tiene un módulo de datos.
Pero con un extra. El formulario todavía está allí, por lo que eventualmente puedo volverlo visible para la determinación del problema. Yo uso el About Box para esto.
Y no, no he experimentado ninguna penalización notable en el tamaño o el rendimiento de la aplicación.
No intento romper el paradigma de MVC. Intento cumplirlo en su lugar. No mezclo los Formularios que constituyen mi Vista con los DataMovules que constituyen mis Controladores. No los considero parte de mi Vista. Nunca se usarán como la interfaz de usuario de mi aplicación. Los DataMovules simplemente son Formularios. Son solo artefactos de ingeniería convenientes.
Bueno, supongo que preferirás * múltiples * datos (m/v) de nódulos. ;) –
Las formas son "pesadas" en comparación con los módulos de datos. Como en realidad son "ventanas" del sistema operativo, utilizan recursos del sistema, tienen un winproc, etc. Los módulos de datos son mucho más livianos. Vea poca necesidad de mostrar un formulario con solo componentes no visibles. Sí, puede imprimir algunos resultados de depuración, en mi humilde opinión hay mejores formas de hacerlo. –
Sí, uso todas las que necesito para organizar lógicamente mi aplicación y promover la reutilización. –
Un módulo de datos solo para sus objetos de tabla, si solo tiene unas pocas tablas db, sería una buena opción para ser el primero.
Y un módulo de datos para sus acciones es otro.
Un módulo de datos solo para listas de imágenes, es otro buen tercer módulo de datos. Este módulo de datos solo contiene listas de imágenes, y luego sus formularios que necesitan acceso a listas de imágenes pueden usarlos todos desde esta ubicación compartida.
Si tiene 200 objetos de tabla, tal vez más de un módulo de datos solo para tablas db. Imagine una aplicación que tiene 20 tablas para hacer con facturación, y otras 20 tablas para hacer con HR. Creo que un Módulo de facturación de datos y un Módulo de datos de RRHH sería bueno separarlos si las tablas dentro de ellos y el código que funciona en contra de ellos no necesitan saber nada el uno del otro, o incluso cuando un módulo tiene una dependencia de "usos" en una dirección, pero esa relación no es circular. Incluso entonces, la modularidad de los módulos de datos más finos puede ser beneficiosa.
Debe volver a escribir el título para indicar más claramente la naturaleza de su pregunta. Probablemente no pueda editarlo, así que lo haré por usted ... –
IMO, los módulos de datos nunca deben hacer referencia a los formularios del proyecto. Si un formulario necesita, por ejemplo, reaccionar a un cambio en un conjunto de datos, coloque un TDatasource en dicho formulario, vincúlelo al conjunto de datos y coloque su código en el evento de TDatasource. –
Volviendo a preguntas como esta años más tarde, me parece interesante observar que, a falta de límites sobre cuánto puede empujar de una forma, módulo de datos o unidad, los desarrolladores de Delphi empujan Way Too Much Stuff en un módulo/Unidad/Archivo en lugar de pensar en lo que tiene sentido real y es mantenible y legible. –