Cita:
Empezado por AzidRain
...De entrada para mostrar todas las facturas lo mas simple es hacer un query y mostrarlo en una tabla, pero coño, entonces donde ha quedao nuestra TFactura. Pensé en una TCollection de TFacturas pero entonces para que coño esta TDataset y los componentes DBAware de Delphi???.
|
Hay que pensar que los componentes de Datos estandard de Delphi no están pensados para este modelo de trabajo. Partiendo de esto yo veo dos posibles soluciones.
* Una intentar "adaptar" los componentes de Base de Datos para trabajar con tu objeto TFactura. En mi caso lo he hecho en una ocasión modificando no directamente los componentes sino el Conector. De esta forma nuevo conector es el que se engancha a tu Base de Datos relacional, te recupera datos y los convierte en objetos del tipo TFactura. Con esto y derivando los componentes estandard puedes conseguir que más o menos funcionen con ese modelo. Si no recuerdo mal, este modelo es el que usaban los InstantObjects.
* La otra opción pasa por crear los componentes desde cero. Con esto conseguirás que tus componentes estén del todo orientados al modelo de persistencia, pero eso implica un trabajo muy arduo y con muchas horas de programación.
He programado ambas soluciones (en dos empresas distintas) y te aseguro que la segunda fue un trabajo de muchas horas y la solución enos convincente que la primera.
Cita:
Empezado por AzidRain
...De tal suerte que para guardar la factura solo llamo a TFactura.Save quien a su vez llama a SaveDetail quien se encarga de guardar el detalle de la factura.
Los constructores normalmente los hago pasádole a la clase una conexión a la BD que utilizo: TFactura.Create(ZMyConnection) (uso Zeos)
|
Aquí estoy de acuerdo con Delphius. El tema de Base de Datos deberías independizarlo de tus clases. Para esto normalmente se usa un Objeto independiente que es el que se encarga de todas las conexiones y "conversaciones" con la Base de Datos (
Gestor). Lo grande de este modelo es su independencia de la Base de Datos. Si mañana cambias de Base de Datos, basta con cambiar el Gestor para que todo funcione correctamente. El realidad lo que se hace es tener un Gestor y derivarlo para cada BD que necesites. De esta forma tienes un sistema ampliable a distintos mnotores de forma sencilla.
Cita:
Empezado por AzidRain
He notado que un efecto adicional es que dejo totalmente independiente la BD de mi modelo de objeto, de manera que si hay excepciones las puedo manejar dentro de mi clase principal sin llegar a la BD más que cuando ya se ha validado casi todo.
|
Correcto. Supongo que debes contar con algun "diccionario"; La definición de las clases TFactura, TCliente y de todos sus campos.
Cita:
Empezado por AzidRain
Me hubiera gustado prescindir por completo de componentes dbaware pero esto requiere mucho más código y terminaría haciendo cosas al estilo Java y en Delphi se supone que todo se puede hacer mucho más rápido.
|
Como ya te he comentado, conseguir prescindir de todos los componentes de DB y conseguir a la vez una aplicación real solvente y ágil, significa que deberías crear tus propios componentes de trabajo. Eso en un trabajo de muchas horas y además no es trivial.
Por lo demás, a mi entender debes tener claras y bien diferenciadas las partes que forman este modelo. Por un lado tu Base de Datos, por otro lado tu modelo y por otro lado un "Gestor de persistencia" que es el que une los dos anteriores y que los hace independientes. Este gestor es el que te convierte los datos de la BD con un modelo relacional en tus objetos del modelo con una estructura de Objetos.
El "modelo" normalmente está formado por tus objetos (TCliente, TFactura,...) y por un diccionario que mantiene y almnacena la estructura y características de esos objetos.