Solicito su opinión sobre mi modelado

[Neftali [Germán.Estévez]]

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.

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.

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.

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.

[[AzidRain]]

En efecto la cuestión de acceder a la BD pretendo dejársela a una clase TGestor del cual pueden descender TGestorFacturas, TGestorClientes, etc. Esta clase por ejemplo sería la que reciba un objeto y lo almacene en la BD y a la inversa lo recupere, busque, etc. Ahorita por cuestiones de tiempo lo he dejado así como les comenté. De hecho cuando haga el cambio solo pasará dos métodos de TFactura al gestor por lo que no preocupa mucho.

Principalmente mi duda de "¿Lo estaré haciendo bien?" radicaba en el uso de TClientDatasets para almacenar temporalmente datos de la BD .Pero creo que no voy tan mal, de hecho me he dado cuenta que aunque dedico 2 o 3 días a modelar, diagramar y demás. Cuando escribo el código generalmente (90%de las veces) funciona a la primera.

[Neftali [Germán.Estévez]]

Empezado por AzidRain

...la cuestión de acceder a la BD pretendo dejársela a una clase TGestor del cual pueden descender TGestorFacturas, TGestorClientes, etc.

No va per ahí la cuestión o al menos yo no me refería a eso.
El Gestor es único. Y Las opreciones sobre la Base de Datos debe hacerlas utilizando un diccionario de Datos.

Si tienes 500 Clases tendrás 500 Objetos (que derivarán de la clase base <TObjetoNegocio>) un diccionario de Datos, donde se almacene de alguna manera la estructura de esos 500 objetos. Un único Gestor (que utilizando la información del diccionario debe ser capaz de realizar todas las operaciones sobre Base de Datos -independientemente de los objetos-) y por último las tablas.

En cuanto al tema de TClientDataSet creo que puede ser una opción acertada; Es más, en nuestro caso estuvimos revisándolos y hay dicumentación donde se explica cómo hacerlo (la mayoría referente a modelos de persistencia en Java, pero que explican las líneas generales).