FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Crear Clases propias o Usar Existentes
Hola.
Os importaria darme vuestra opinion, sobre este tema?. A la hira de crear una aplicacion de Gestion, vosotros como programadores experimentados, usarias las clases de conexion con BD exitentes para el 100% de la aplicacion ? o por el contrario usariais vuestras propias clases que a su vez usen las de Acceso a BD?. Elp roblema seria que no podrias usar los componentes de acceso BD no ?
__________________
Gracias de Antemano |
#2
|
||||
|
||||
¿Puedes explicarte un poco mejor? No acabo de entender.
No se pueden usar componentes de Base de Datos. ¿A qué clases te refieres?
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#3
|
|||
|
|||
Me refiero pues por ejempplo que uses los componentes de ADO, TAdoTable, TAdoConnection y luego usar el componente TDBEdit por ejemplo para recuperar el nombre de un articulo de la BD? y usar estos componentes TDBEdit, TDBCombo, etc,....
Pôr otro lado a lo que me refiero es crear una clase que sea por ejemplo
Ahora habiora que crear un Objeto de la clase, largarllo de la BD con su metodo y usarlo en el codigo. Pero entonces ya no podrias usar el TDBEdit por ejemplo. Tendrias que usar el TEDit y hacer la asociacion de controles y propiedades del objeto a mano. ¿Me he explicado mejor?, si no lo intento de nuevo
__________________
Gracias de Antemano |
#4
|
||||
|
||||
Ok, ahora entendí un poco mejor (o creo).
Hablamos de usar componentes estandard DataAware (TDBEdit) o utilizar una capa de persistencia on componentes no-DataAware (TEdit). Cita:
Cita:
Creo recordar que los InstantObject funcionaban de forma similar; No se como lo hace ECO, porque no he trabajado con él... Espero que te sirva la información y no haerte liado más de la cuenta. Si tienes más dudas, no "dudes" en preguntar. Un saludo.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#5
|
||||
|
||||
Cita:
Cita:
Siento que en realidad no estoy entendiendo lo que quieres decir con los párrafos anteriores. ¿Podrías explicar un poco más? Similar a esto, he visto lo que menciona Wayne Niddery aquí pero no sé si es a eso a lo que te refieres. // Saludos |
#6
|
||||
|
||||
Cita:
A eso me refería a "rediseñar/derivar" el TDataSet(o derivado) para poder hacer lo que necesitemos; Acceder al modelo de persistencia, ejecutar las reglas de negocio,... y finalmente insertar utilizando SQL (en mi caso). Cita:
NOTA: Ahora me leo en artículo...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#7
|
||||
|
||||
Cita:
Moving data between controls and a data source in no way compromises an OO design because data sources (i.e. TDatasource) do not directly connect to a database and have absolutely no knowledge of the ultimate source or destination of the data that passes through them. Their only role is to provide a single point of connection for any number of individual data-aware controls. That single point of connection is to any descendant of the TDataset class. Los controles de Base de Datos (TDBEdit, TDBCombo,...) no son el problema; La "miga" y la potencia está realmente en el TDataSet (DataLink); Además, derivado adecuadamente es el que te puede proveer de un FrameWork independiente del SGBD. Y esto creo que da la respuesta: Summary Existing data-aware controls are perfectly compatible with well-designed object-oriented systems. The scorn placed on them by many has been misplaced; the real problem is the routing of data; data-aware controls hooked to datasets that have actual database connections is the problem since this allows data to flow around business logic instead of through it. But it is a problem solved easily by making your business classes responsible for creating the datasets seen by the presentation layer. Se trata de que los componentes traten con un TDataSet y cortar el flujo de información entre el TDataSet y la Base de Datos, pasándolo al Gestor de Persistencia; Es el Gestor de Persistencia el que se comunica con el SGBD (en nuestro caso en lugar de vía TClientDataSet, como comenta el artículo, utilizando SQL). A esto me refería con "no grabar de la forma estandard"; En el artículo habla de utilizar un ClientDataset, yo pensaba en SQL directamente.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#8
|
||||
|
||||
Sin ver mas alla...
Me parece que si hablas de un programa de gestion, estamos hablando de un sistema con varias formularios, funciones, manejo de archivos, etc, etc... Lo que en definitiva te aconsejo usar es una clase existente para concentrarte mas en lo tuyo, si te pagaran bien (por ejemplo). yo siempre acostumbro crear mi propio formato y motor de base de datos, asi consigo lo que exactamente necesito y de una forma que pocos podrian hackear.
|
#9
|
||||
|
||||
Hola,
Cita:
|
#10
|
||||
|
||||
Explicacion
bueno, formato... defino mi "cabacera" (hash, propietario, privilegios, version, etc), defino mis campos de tablas, mis tablas etc, etc... digamos que trabajo con un "archivo plano"... lo que todos hacen... Una vez hice uno que trabajaba con posiciones absolutas de disco duro bajo el S.O. pero no lo llegue a implementar. consigo BDs de pocos Kb y veloces... dedicados a ser parte de aplicaciones mas que a medida.
En motores, los sub-sistemas que me permiten acceder via SQL (basico), funciones de comprobacion, bloqueo, privilegios, Sockets para trabajar en red, pseudo - triggers, y eso.. |
#11
|
||||
|
||||
Yo tengo una pregunta también.
Si yo empecé con paradox, creando mis clases y mis rutinas de apoyo; después he pasado a Firebird y he hecho lo mismo; ahora me decís que la persistencia es la monda ... si estoy cambiando de esquema de programación cada dos por tres, ¿Cuando voy a reutilizar las clases y rutinas de apoyo que tengo hechas? Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#12
|
||||
|
||||
Hola,
Desengáñate Lepe, nunca podrás reutilizar ninguna clase. |
#13
|
||||
|
||||
Tampoco.
No dije cual es la moda... digo lo que yo en persona prefiero hacer siempre que la relacion costo/beneficio y tiempo me lo permite. Ahora con el asunto de reutilizacion de tus clases (lepe), pues en definitiva es un problema... habría que evaluar cuanto vale la pena realizar dicha "migracion" , es muy probable que te cueste arto reutilizar tus definiciones antigüas, yo en ese caso crearia una interfaz compatible, un motor que reconozca dichas clases.
Suerte! |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Lista con los informes existentes en una BD en Access | zerelho | Servers | 2 | 02-06-2006 01:14:32 |
crear clases en delphi | alextmb | Varios | 6 | 24-04-2006 01:40:45 |
Conocer ip de las conexiones existentes | anduj | Firebird e Interbase | 8 | 01-03-2005 15:50:14 |
Definir Mis Propias Clases | jberaza | OOP | 1 | 27-09-2004 17:11:08 |
Crear librerias propias en delphi | Jan_polero | OOP | 5 | 15-05-2004 13:29:04 |
|