Club Delphi  
    Paypal   FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > OOP
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Coloboración Paypal con ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 05-09-2005
Avatar de Crandel
[Crandel] Crandel is offline
Miembro Premium
 
Registrado: may 2003
Ubicación: Parana, Argentina
Posts: 1.475
Poder: 25
Crandel Va por buen camino
Pues yo creo que al utilizar Delphi, normalmente uno hace POO (tambien se puede hacer programación estructurada pero es diferente).

Cuando iniciamos un aplicación, Tenemos por defecto creada una clase llamada TForm1 descendiente de TForm, hay declarada una instancia de TForm1, por lo que se termina creando un objeto del mismo.

Colocamos un Botón sobre nuestro formulario y y Tenemos una instancia de TButton llamada Button1 que a su vez esta contenida dentro de TForm1 (clases contenedoras).

Hacemos doble click sobre nuestro Button1 y comenzamos a escribir nuestro código. Estamos escribiendo el código que será ejecutado ante un evento OnClick.

No creo que esto sea programación estructurada.

Lo que pasa es que Delphi nos la hace muy fácil y nos libera de un montón de cosas.

Ahora tambien podemos y en muchos casos es necesario crear nuestras propias clases.

Cita:
Empezado por Crandel
En general cada uno de ellos va a estar relacionado con un formulario, por lo que en general no es necesario crear nuevas clases. Sin embargo puedes separar la parte visual de los formularios creando una clase que se encargue de manipular el acceso a cada tabla (se complica mas el diseño).
Explicando lo que comente antes, podriamos diseñar una clase llamada TClientes, de la siguiente forma:

Código Delphi [-]
TCliente = record
  Nombre: string;
  Direccion: string;
  ...
end;

TClientes = class
private
....
public
  procedure AgregarCliente(cliente: TCliente);
  procedure BorrarCliente...
  ...
end;

Donde en esta clase encapsulemos nuestro acceso a la base de datos, de manera que en nuestra aplicación no nos importe en que tipo de motor estamemos guardando o si estamos guardando nuestros datos en un archivo de texto.

Cuando querramos modificar el lugar donde se guardan los datos simplemente modificamos esta clase y el resto de la aplicación sigue como si nada.

Espero haber sido claro.
__________________
[Crandel]
Responder Con Cita
  #2  
Antiguo 05-09-2005
tramjauer tramjauer is offline
Miembro
 
Registrado: ene 2005
Posts: 42
Poder: 0
tramjauer Va por buen camino
Muy buenas de nuevo, esta manera propuesta por Crandel es la que estaba buscando y la que tenia en mente, lo que pasa es que no se como se tiene que montar esta/s clases, ya que los diferentes componentes para el acceso a la BBDD no se donde irían si en el formulario donde tengo diseñada la aplicación o si irían en la nueva clase creada (ej. TCliente). Si alguien me lo pudiera explicar bien o enviar-me algún ejemplo de como se define una clase nueva para después poder llamar a los diferentes constructores y métodos y poder así trabajar con los objetos, estaría muy agradecido. Además también donde irían los diferentes componentes para el acceso a la BBDD si en la clase TCliente o si en el diseño de l’aplicación.

Muchas gracias de nuevo.

Tram.
Responder Con Cita
  #3  
Antiguo 05-09-2005
Avatar de Crandel
[Crandel] Crandel is offline
Miembro Premium
 
Registrado: may 2003
Ubicación: Parana, Argentina
Posts: 1.475
Poder: 25
Crandel Va por buen camino
Hola, recuerda que de esta forma estmos ocultando el acceso a fuente de datos (la base de datos), por lo que no pueden estar los componentes en el formulario, ni en un DataModule, tienen que estan dentro de la clase.

Es esta clase la que te tiene que servir de interfaz para cualquier acción que quieras realizar con los clientes.

Lo mismo debes hacer practicamente con cada tabla.

Luego dentro de las mismas clases debes comenzar a establecer las relaciones.

Donde se complica un poco más es en relacionar los datos con los componentes.

No es fácil, pero cuando lo terminas queda espectacular.
__________________
[Crandel]
Responder Con Cita
  #4  
Antiguo 05-09-2005
tramjauer tramjauer is offline
Miembro
 
Registrado: ene 2005
Posts: 42
Poder: 0
tramjauer Va por buen camino
Lo siento Crandel pero no te he entendido del todo bien.

Segun lo que he entendido Me dices que en el Data Module ponga la conexion , y todo lo que son AdoTablas,Adoqrys, etc. de la clase Tcliente las ponga dentro de la misma clase. NO? pero si es solo una clase no tiene formulario no?(corrigeme si me equivoco) Y entonces qualquier insercion, modificacion o eliminacion pasaran por esta clase, no?

+ "Luego dentro de las mismas clases debes comenzar a establecer las relaciones." ---> A que te refieres?

+ "Donde se complica un poco más es en relacionar los datos con los componentes." ---->Porque se complica un poco mas lo unico que se tiene que hacer es hacer uso de las diferentes clases creadas (TCliente) en el uses no?

Y la estructura para declara la clase como seria? Ya que e visto de muchos tipos y ninguna igual. Y no se si se tiene que seguir alguna plantilla o que.

Muchas gracias de nuevo y siento ser tan pesado!:P
Responder Con Cita
  #5  
Antiguo 05-09-2005
Avatar de Crandel
[Crandel] Crandel is offline
Miembro Premium
 
Registrado: may 2003
Ubicación: Parana, Argentina
Posts: 1.475
Poder: 25
Crandel Va por buen camino
Cita:
Empezado por tramjauer
Lo siento Crandel pero no te he entendido del todo bien
no hay problema.

Cita:
Empezado por tramjauer
Segun lo que he entendido Me dices que en el Data Module ponga la conexion , y todo lo que son AdoTablas,Adoqrys, etc. de la clase Tcliente las ponga dentro de la misma clase. NO?
Todo va dentro de la clase. Esta clase es la unica que sabe acceder a los datos de los Clientes.

Cita:
Empezado por tramjauer
pero si es solo una clase no tiene formulario no?(corrigeme si me equivoco) Y entonces qualquier insercion, modificacion o eliminacion pasaran por esta clase, no?
SI

Cita:
Empezado por tramjauer
+ "Luego dentro de las mismas clases debes comenzar a establecer las relaciones." ---> A que te refieres?
Por ejemplo, si tus clientes contratan Servicios, vas a tener tu clase TServivios. De alguna forma tenes que establecer la relación de que Servicios tiene contratado cada Cliente.

Cita:
Empezado por tramjauer
+ "Donde se complica un poco más es en relacionar los datos con los componentes." ---->Porque se complica un poco mas lo unico que se tiene que hacer es hacer uso de las diferentes clases creadas (TCliente) en el uses no?
Todos los componentes de la paleta Data Controls, ya tienen establecida la interfaz para acceder a los datos a traves de un DataSource, vos en este caso no lo tenes.

Cita:
Empezado por tramjauer
Y la estructura para declara la clase como seria? Ya que e visto de muchos tipos y ninguna igual. Y no se si se tiene que seguir alguna plantilla o que.
El resto de la estructura es tu trabajo , no creo que exista alguna plantilla.
__________________
[Crandel]
Responder Con Cita
  #6  
Antiguo 06-09-2005
tramjauer tramjauer is offline
Miembro
 
Registrado: ene 2005
Posts: 42
Poder: 0
tramjauer Va por buen camino
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.
Responder Con Cita
  #7  
Antiguo 06-09-2005
adlfv adlfv is offline
Miembro
 
Registrado: may 2005
Posts: 39
Poder: 0
adlfv Va por buen camino
Hola.

Cita:
1.- Según me dices todos los componentes (ADOConnection, ADOQry, ADOTable, etc...) van en el formulario de la clase (ej. Tcliente), no?
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.

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:
2.- Entonces si tengo muchas clases como es normal que tendré muchos ADOConnection?
No me parece lo correcto. Aunque tengas muchas tablas, la base de datos es una, con lo cual sólo debería haber (en mi opinión) una conexión a la base de datos. Lo que sí hay son vinculaciones de dicha conexión a las clases que acceden a los datos. Cuando trabajas de forma clásica pones una conexión, y tienes por ejemplo 5 tablas, pues a las 5 tablas le asignas la propiedad Connection a la conexión. Pues aquí pasa igual, tienes una conexión, pero las clases son vinculadas a ésta.

Cita:
4.- Entonces si no tengo el Componente DataSource como accedo y muestro los datos en los formularios? Mediante los diferentes metodos?
En esto no te puedo ayudar, pues esto tampoco lo tengo muy claro... Me imagino que puedes hacerlo de dos formas, usando componentes DB Aware (DBEdit..) o usando componentes normales (Edits...) cómo cargarías los datos, si usas Edits normales, con métodos... Por ejemplo imagina la clase cliente... Tiene las propiedades Nombre y Apellido: String; Apellido... Pues al asignarle la propiedad en genral usas un método GetNombre: String y GetApellido: String... Luego en el método de busqueda por cliente haces algo tal que así:

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
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

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


La franja horaria es GMT +2. Ahora son las 23:54:57.


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