Club Delphi  
    Paypal   FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Varios
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Coloboración Paypal con ClubDelphi

 
 
Herramientas Buscar en Tema Desplegado
  #7  
Antiguo 25-06-2008
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
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
Responder Con Cita
 



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Remote DataModule rodalvi Providers 0 16-05-2007 09:29:51
Error en DataModule MasterXP OOP 2 05-10-2005 03:37:35
Datamodule VRO Firebird e Interbase 2 13-07-2004 19:00:45
Dudas con el DataModule ramonibk Conexión con bases de datos 3 09-07-2004 12:48:15
datamodule maruenda Varios 1 31-12-2003 18:24:21


La franja horaria es GMT +2. Ahora son las 20:42:32.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi