Ayuda con el dissenyo de una aplicacion. Clases o no?

[adlfv]

Hola.

Creo que hay una pequeña confusión, o al menos así lo percibo yo...

La programación en Delphi (desde mi punto de vista) no es orientada a objetos al 100%... Por ejemplo, usar componentes DB Aware, es un tema un tanto complejo en donde encontrarás mucha diversidad de criterios.

Te recomiendo que le eches un vistazo a lo que se denomina "mecanismo de persistencia de objetos" o en ingles "Object Persistent Framework"... En definitiva creo que tal ve es eso lo que preguntas. Esto consiste en trabajar a nivel de clases para la información, es decir, si manejas clientes en tu aplicación, tendras una clase TCliente con métodos para por ejemplo agregar un cliente, borrar un cliente, buscar clientes por ID, nombre... y todo lo que se te pueda ocurrir relacionados con clientes. Lo que comento de Object Presistent Framework o OPF (ver "tiOPF" en google) permite hacer esto precisamente. Esta forma de programar francamente no la he usado, pero estoy intentando leer y averiguar sobre esto, pues creo que para programas grandes es conveniente plantearse esto desde un principio.

Puedes seguir la otra línea que es los componente DB Aware en el desarrollo clásico que plantea Delphi (usar TTables, TQuerys, TDataSource, TDataModule..), pero ahora te pregunto, te ha pasado que tengas que cambiar el nombre de un campo de una tabla, donde uses mucho ese campo en tu aplicación? Es tedioso de mantener.

Otra opción que también he leido por ahí, y es la que estoy intentando seguir con un programa más o menos grande que estoy desarrollando es como un "hibrido", que plantea usar clases para la manipulación de datos, y poder usar DB Aware en algunas cosas. Por ejemplo la idea que tengo es usar clases principalmente para el "ingreso" de datos, y lo que son mantenimientos, usar DB Aware. Tal vez me salga el tiro por la culata y me quede con los inconvenientes de ambas técnicas . Espero que no, pero como también estoy aprendiendo sobre esto, todavía no puedo opinar con conocimiento de causa, sino dar ideas...

No sé si a eso es a lo que te referías, o si te he confundido aún más.

Si en algo estoy equivocado, por favor diganme.

Un cordial saludo.

[[Crandel]]

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.

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.

[tramjauer]

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.

[[Crandel]]

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.

[tramjauer]

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

[[Crandel]]

Empezado por tramjauer

Lo siento Crandel pero no te he entendido del todo bien

no hay problema.

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.

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

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.

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.

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.

[tramjauer]

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.