![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||||
|
||||||
|
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
, no creo que exista alguna plantilla.
__________________
[Crandel] |
|
#2
|
|||
|
|||
|
Muy buenas de nuevo jejeje
Haber si me queda claro de una vez: (es que me quiero asegurar) 1.- Según me dices todos los componentes (ADOConnection, ADOQry, ADOTable, etc...) van en el formulario de la clase (ej. Tcliente), no? 2.- Entonces si tengo muchas clases como es normal que tendré muchos ADOConnection? 3.- Lo de establecer las relaciones me ha quedado claro! 4.- Entonces si no tengo el Componente DataSource como accedo y muestro los datos en los formularios? Mediante los diferentes metodos? Espero que con tu respuesta se terminen mis dudas. Muchas gracias de nuevo. Tram. |
|
#3
|
|||
|
|||
|
Hola.
Cita:
. La clase TCliente no es un formulario, es una entidad de datos (o conjunto de datos), es como si fuera una simulación de una tabla clientes de tipo TDataSet, pero con métodos propios.Veamos un ejemplo para intentar aclarar algunas cosas, imagina un modelo entidad relación, donde tienes Clientes, paquetes y servicios. Un cliente puede adquirir 0 o 1 paquete, y un cliente puede adquirir uno o mas servicios. De esa forma, una posible implementación es que tengas por ejemplo una tabla "Clientes-Servicios" y el paquete que adquiere el cliente, lo pones como un atributo en la tabla de la transacción (relacionado con la tabla paquetes) por ejemplo "Compras". De esta forma (por ejemplo), tendrías las clase TCliente, TCompras, TServicios, TPaquetes. La clase compra tendría una propiedad que sería el cliente, o el ID del cliente. La clase TServicio, pudiese tener por ejemplo un método para buscar por precios, o por popularidad devolviendolos en un TStrings, y cosas así... Ya eso depende de lo que el problema requiera. La clase TCompra, pudiera tener un método por ejemplo para contratar un paquete, y pudiera tener métodos para contratar servicios... Cita:
Cita:
EdtNombre := Cliente.Nombre; // O Cliente.GetNombre si no usas propiedades.. EdtApellido := Cliente.Apellido; Pensandolo bien... Creo que no se pueden usar componentes DB Aware, pues todos se vinculan a un DataSource y éste sólo se puede vincular a una tabla... Sería interesante si existieran TDataSet "virtuales" que no se vinculen a la base de datos, sino que sean controladores de datos en los que tú cargas los datos como en una tabla virtual para que después puedas usarlos... Espero que te sirva y te oriente lo que te digo. Un cordial saludo, y ánimo que estamos en las mismas ![]() |
|
#4
|
|||
|
|||
|
Buenas, me parece que no m’he has entendido o lo has leído mal:
- No necesariamente tendrás un formulario para cada clase. Hablamos de clases "a lo bestia" jeje . La clase TCliente no es un formulario, es una entidad de datos (o conjunto de datos), es como si fuera una simulación de una tabla clientes de tipo TDataSet, pero con métodos propios.à Ya lo se que la clase TCliente no es un formulario, lo que yo preguntaba es que si todos lo componentes ADO van en la clase (como habia dicho el amigo Crandel), digo yo que se tendrán que poner en un formulario no¿? I sino donde? - Entonces si tengo muchas clases como es normal que tendré muchos ADOConnection? à Entonces según tu la conexión ira como siempre en el dataMolule no¿? - Por todo lo demas muchas gracias. Tram. |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
|