Arquitectura en código de un sistema de BD

[faraonDX]

Delphius, ahora es ud el que no da señales de vida. JJAAA vamos tu no eres tan callado.

Estoy trabajando, Estoy consultando algunos tutoriales y ejemplos que he visto en internet para ver si me puedo explicar mejor todavia, auque en uno de los ultimos mensajes me dijiste que habías bajado el articulo que viene un ejemplo si analizas este caso te daras cuento de lo que estoy hablando, he visto en otros post que le das un especial interes al (analisis - diseño), de todas forma no tengo apuro cuando pudas dar una respuesta las das, estoy tambien pensando en crear otros hilos que tienen que ver con este tema, hice otro de ModelMaker, me gustaría que tambien opinaras al respecto.

Nos Vemos....

[[Delphius]]

Hola FaraonDX, disculpa... por mi ausencia.

Leí el artículo una y otra vez... y cuando leo y repaso mi percepción sobre el asunto, se me hace una ensalada y no me termino de convencer.

Yo estoy haciendo algo parecido a lo que dice el artículo. Aunque me llama mucho la atención lo de udmAuto y udmGeneral. Eso no termino de comprender. Yo estoy explorando el territorio de la base de datos con Delphi a medida que me hace falta para continuar con mi trabajo. Una formación y conocimientos expertos en el área no tengo.

Yo hago esto: mi capa lógica está divida en dos apartados: una sección a la que denomino API (que está constituída por funciones y estructuras de datos sencillas) y otra sección compuesta por clases. Las clases hacen uso de dichas API si es necesario.

La idea y percepción de la comunicación con las otras capas es empleando los eventos de componentes abstractos: DataSource, etc...
Y lo que estaba tratando de explicar es que los objetos creados operan con los datos, los transforman. Cuando se es necesario, al objeto se le envian los datos necesarios.

Luego esos datos deben ser devueltos ya sea a la capa de interfaz o la de datos. En este punto mi visión y modelo no logra explicar como hacerlo... y es aquí donde me he quedado trabado.

Lo que yo trato de hacer es separar las clases y la invasión de datos. Para mi las clases deben trabajar y transformar los datos.

En cuanto al diagrama que está en el documento, es (a mi entender) que las mismas clases cuentan entre sus propiedades controles para el acceso a los datos (un datamodule). Y es gracias a ello que cuando se invocan a los eventos se pasan los datos a las clases.

Es cierto que el uso de los controles dataware ahorra mucho dolores de cabeza (y ahora estoy entendiendo porqué). Pero me está convenciendo la idea de que los componentes dataware + POO no es aconsejable para un sistema que está pensado para ser escalable y que necesitará de mantenimiento y que sea complejo.

Para un sistema sencillo, y en el cual se sabe de antemano que no requerirá de ampliaciones, migraciones.... lo más económico es usar controles dataware.

Recuerdo haber visto unos hilos (hace ya mucho tiempo) con ejemplos de "POO+DB" Los he estado buscando pero al parecer fueron extraviados en aquella rotura del disco del servidor que sufrio clubdelphi. Recuerdo haber visto que entre sus propiedades contaban con elementos query.

Creía y daba por sentado que entendía bien el asunto... ya veo que tener los planos es distinto que codificarlos.

Lamento no poder ayudar demasiado. El asunto quedó igual.
Estoy tratando de unir lo que dice el documento con lo que leí en la Cara Oculta...

Si un mejor entendido del tema pasa por aquí, nos puede refrescar la memoria a ambos.

Saludos,

[faraonDX]

Ohh que bueno que sigues en contacto.

Veo que ya entendiste esactamente el problema. Leí atentamente el comentario que hiciste anteriormente y estoy de acuerdo totalmente, al parecer tengo el mismo problema cuando expresaste:

Es cierto que el uso de los controles dataware ahorra mucho dolores de cabeza (y ahora estoy entendiendo porqué). Pero me está convenciendo la idea de que los componentes dataware + POO no es aconsejable para un sistema que está pensado para ser escalable y que necesitará de mantenimiento y que sea complejo.

Esto lo leí en un curso que habla más o menos del tema, no esactamente:

Código PHP:

El paradigma de objeto de negocios es muy útil, pero nos ocasiona muchos problemas que Delphi ya había solucionado en cuanto a la programación de base de datos. El diseño de los objetos de negocios en sí totalmente ignora el concepto del DataSet, y con ello, los controles data-aware. Esto quiere decir que, en una implementación "pura" de un objeto de negocios, usted deberá de 1) utilizar controles normales y escribir una gran cantidad de código de infraestructura, o 2) crear su propio descendiente de TDataSet que funcione con cada uno de sus objetos de negocios. 


De todas forma yo sigo tratando de descubrir la verdad. Espero que no te des por vencido y sigas investigando como lo estoy haciendo yo, cualquier comentario que que emitas según tus análisis , por favor escribelos pués son utiles.

Tambien pienso que deben participar otras personas del club. Yo voy a tratar de convocar a otras personas, a ver si se le saca probecho.

Saludos.