Arquitectura en código de un sistema de BD

[faraonDX]

La verdad es que se comenta mucho de como hacer esto lo otro, pero no he podido tener la oportunidad, de consultar con otras personas: cuál es el procedimiento a seguir desde el punto de vista arquitectonico para diseñar sistemas de base de datos, es decir cuantas unit debe tener la aplicación según el análisis y diseño realizado anteriormente y en cual introdusco esta clase o la otra, aunque tengo mi propio estilo para el diseño, pienso que debe existir una manera estandar de hacer las cosas principalmente para los sistemas de Base de Datos que claro en delphi manipula muy bien sobre todo con los controles Dataware, mi pregunta es la siguiente ¿Puedo utilizar estos controles en un sistema diseñando OO? si lo puedo utilizar ¿Como es que lo utilizo en las clases si existe una relación de modelo de tres capas ?

Espero que entiendan mis ideas y que me ayuden a aclarar el tema.

[Ñuño Martínez]

A ver: Object Pascal tiene soporte OO nativo, ¿no? Entonces, ¿por qué dudas de que pueda hacerse?

[[Delphius]]

Hola FaraonDX, bienvenido a clubdelphi.

No se si estoy entendiendo bien tu pregunta. Tu dirás si me equivoco.

Empezado por FaraonDX

cuál es el procedimiento a seguir desde el punto de vista arquitectonico para diseñar sistemas de base de datos, es decir cuantas unit debe tener la aplicación según el análisis y diseño realizado anteriormente y en cual introdusco esta clase o la otra

La cantidad de unit que deberá tener una aplicación es como tu dices: dependerá del análisis y diseño que se haya realizado anteriormente. No es tan sencillo poder encontrar la cantidad de unidades (módulos) exacta para llevar a cabo tu aplicativo.
POr más empleo de métricas, y buenas prácticas que uses para determinar tanto el acomplamiento y cohesión que hay presente entre los módulos (y en el módulo). Hay un factor subjetivo que afecta (en mi experiencia) en forma proporcional a la complejidad del sistema.

Una primera aproximación para determinar la cantidad de unidades puede ser esta:

La cantidad de módulos o unidades responde a la cantidad de entidades y/o a la cantidad de tablas de su base de datos.

Es decir que si en tu base de datos hay 10 tablas, tu sistema puede llegar a tener alrrededor de entre 7 y 13 unidades. (Consideré un factor de error del 30%) Suponiendo que estamos en la etapa de estimación, considerar este porcentaje de error (30%) es válido. Pero si estamos en la etapa de construción este factor debería ser por lo menos la mitad, ya que se supone que la mayoría de sus requisitos y análisis ya fueron validados y validados. El factor debería ir decreciendo a medida que se avanza.

Empezado por FaraonDX

aunque tengo mi propio estilo para el diseño, pienso que debe existir una manera estandar de hacer las cosas principalmente para los sistemas de Base de Datos

El estandar de diseño por excelencia para POO es UML. Y sería recomendable su uso. Recuerda que el estándar está para ser usado y permite hablar del mismo tema sin temor a interpretar erroneamente lo que otro ha diseñado. Es un lenguaje común que favorece la comunicación y entendimiento. ¿Es bueno saber que si tu te pierdes, otro te puede hablar en tu mismo idioma, no crees?

Empezado por FaraonDX

¿Puedo utilizar estos controles en un sistema diseñando OO? si lo puedo utilizar ¿Como es que lo utilizo en las clases si existe una relación de modelo de tres capas ?

¿Que te impide emplear los controles dataware? Por algo están...

No se como debería interpretar la parte de modelo de tres capas. He visto muchas definiciones de lo esto significa. En lo personal, tres capas significa para mi esto:

-------------
Capa Interfaz -> Entrada y Salida de datos.
-------------
Capa Lógica -> Clases, y/o funciones o procedimientos que operan sobre los datos ingresados y/o recuperados de la base datos (para luego mostrarlos)
-------------
Capa Datos -> Módulo de datos (DataModule), Base de datos.
-------------

Si es que lo que entiendo por tres capas es correcto, y viendo lo que comentas sobre dataware, estos están en la capa de Interfaz, ya que se adosan a esta última. Ten en cuenta que estos componentes responderán a las fuentes de Datos (DataSource, etc).

Ahora, veo que parece que estás siguiendo un enfoque OO (Sería lógico. ya que es un punto fuerte que ofrece Delphi).

Por un lado tienes las units que responden a tu interfaz y por el otro las que tienen definida toda tu estructura (diagrama de clases) con sus jerarquías, relaciones, etc... Y por el otro las más bajas: la de datos.

La pregunta a la respuesta ¿Cuantas unit son necesarias? Debe responder a estos 3 tipos de units.
Como dije antes:

Empezado por Yo

a la cantidad de entidades

Una clase es una entidad. Eso lo sabemos, y dicha clase puede (no necesariamente) ser una representación de alguna tabla. Por lo tanto deberías contemplar este caso: estarías contando doble (la de lógica y de datos)

La cantidad de units responderá en sintesis a una compensación y equilibrio entre tus tres capas.

Me encantaría seguir comentando sobre lo referente a la capa lógica. Pero esto sería oportuno dedicarlo y tratarlo en un hilo aparte.
Como recomendación, deberás tener en cuenta que la cantidad de unidades lógicas a contar responderá también a esta pregunta:

¿Consideramos todas las unidades que respondan al arbol de jerarquía? ¿O por el contrario, sólo las que responden en la especialización para responder al problema en cuestión?

Esta última pregunta es vital saber responder. ¿Cuántas contar?
Veamos con un ejemplo: tienes 15 clases, por comodidad cada una declarada en una unidad diferente. De estas 15, 5 son desdendientes. Estas 15 clases fueron definidas en un momento anterior y son para propósito general.

Te da un sistema para hacer y notas que puedes reutilizar la clase inferior que mantienen una relación de herencia (las 5). La pregunta es: ¿Incluirías a la cuenta, las 5 de propósito general , las 15 en su totalidad, o sólo la que empleas para heredar y trabajar?

Lo que trato de decirte es que deberás saber donde termina y comienza tu sistema. Seguir un modelo OO tiene sus claras ventajas pero al momento de la reutilización de módulos y unidades se hace confuso hacer una estimación para llevar el análisis y diseño de tu sistema.

En síntesis. Deberás responderte.

¿Donde termina la unión de lo que hace al sistema y comienza lo que responde al propósito general?

Ante cada nuevo sistema, hay un nuevo análisis. Y esta misma pregunta se repite justo en el primer momento de inicio del proyecto. Es necesario saber dar la respuesta, hay que estimar el tamaño, de ello dependerá el buen diseño y evitará confusiones en el futuro.

Espero haberte sido de ayuda. Y si entendí mal, mil disculpas.

[faraonDX]

Me alegra mucho que hallas, respondido a mis interrogantes, he visto algunos comentarios tuyos en diferentes temas y estoy de acuerdo en casi todos. En realidad tambien pienso que antes de escribir una linea de código hay que tener claro la idea esacta de como quedará el sistema, proyectando una arquitectura en la cual se apliquen los diferentes patrones de diseño, es presisamente esto lo que nos permite tener una mayor reusablidad del código y un facil mantenimiento del sistema.

De todas formas todavia me queda la duda de los controles dataware, comentaba anteriormente sobre el modelo de tres capas los controles dataware a mi juicio pertenecen a la capa de interfaz, estos a la hora de implementar un sistema se relacionan con el datasource que pertenece a la capa lógica y los componentes dataset(adotable) pertenece a la capa de datos, por la relación anterior es que me imagino, "a lo mejor estoy equibocado" despues de un diseño OO no podría o mejor dicho no me sería factible utilizar este tipo de relación entre componentes, ya que los objetos que diseño son los que deben estar en relación con los elementos de la interfaz de usuario.


Gracias por acudir a mis interrogantes espero que sigas comentando sobre este tema.

[[Delphius]]

Hola de nuevo faraonDX.

Empezado por faraonDX

Me alegra mucho que hallas, respondido a mis interrogantes, he visto algunos comentarios tuyos en diferentes temas

¿Lo dices por mi? No se que pensar... que alguien lea mis post y comentarios y que esté de acuerdo... me pone rojo de vergüenza. Ja... no... broma. Ta todo bien.

Empezado por faraonDX

En realidad tambien pienso que antes de escribir una linea de código hay que tener claro la idea esacta de como quedará el sistema

No tiene que ser exacta. Pero si lo mejor estimada y precisa posible. Al menos yo, por el momento no me podría decir que mi análisis y diseño será exacto y que siempre será para bien.

Empezado por faraonDX

despues de un diseño OO no podría o mejor dicho no me sería factible utilizar este tipo de relación entre componentes, ya que los objetos que diseño son los que deben estar en relación con los elementos de la interfaz de usuario.

¿A que te refieres a que no te gusta el modo en que se relacionan los componetes? Es la manera en que se trabja en Delphi. ¡Los dataware deben estar ligados a las fuentes de datos para funcionar!

¿A que haces referencia cuando dices en relacion con los elementos de la intefaz de usuario?

Por lo que logro entender (corrije por favor si me equivoco), tu tienes un diseño basado en OO. Bien perfecto. Creo que tu problema radica en como hacer comunicar tu capa lógica con tu capa de interfaz. Y por la forma en que vienes redactando tu problema es que empleas elementos dataware y estos se comunican derechito con la capa lógica (datasource).
Ve al diseño de la capa pero con zonas:

----------------------------------------------------------------------
Capa Interfaz:
Zona 1: controles simples - Zona 2: controles dataware
----------------------------------------------------------------------
Capa Lógica:
Zona 1: Tu diseño lógico: Clases - Zona 2: Datasource
----------------------------------------------------------------------
Capa Datos:
Zona 1: Datamodule, xxDataBase, Table, etc...
----------------------------------------------------------------------

Es decir, Se tiene dos canales de trabajo, por un lado el conformado por el repertorio de controles aportados por delphi (dataware, datasource, etc) lo que conforma un diseño en tres capas. Y en forma paralela tu diseño.

Ahora que lo veo, posiblemente Table, Query pertenezcan a la capa lógica. Habría que ver que opinan el resto. Bueno, en fin el resultado será el mismo.

Para hacer comunicar tus objetos con la interfaz (independiente del control que sea) se emplean los eventos necesarios que deban dispararse... y pasar el valor de los datos:

Código Delphi [-]
TuForma.TuControlEvento(parametros);
begin
   TuObjeto.Propiedad := Valor a tomar;
   TuObjeto.Evento;
end.

// O....

TuUnidad.TuControlEvento(parametros);
begin
   TuObjeto.Propiedad := Valor a tomar;
   TuObjeto.Evento;
end;

Y esta filosofía es la que permite que se envién y pasen los mensajes entre tus objetos y después envien los datos hacia el receptor correspondiente.

Por ejemplo puedes aprovechar alimentar a tu objeto cuando los datos han cambiado (on Change de un Data Source). El momento indicado de cuando pasar los datos a tus objetos dependerá del diseño de tus diagramas de secuencia (son fabulosos para ver estas cosas) y otros diagramas que UML nos ofrece.

El ejemplo es muy simple...
No tengo un ejemplo preparado (código) para que te ilustre mejor la idea. He visto unos ejemplos de BD y POO en varias ocasiones en estos foros. Busca con esos términos.

Te puedo recomendar que leas UML y patrones. de Craig Larman, si es que no lo haz leído todavía.

Creo que los maestros te pueden dar una mejor perspectiva del asunto.
No se si termino de explicarte, y de explicarme. Lo más probable es que haya quedado tinta en el tintero por mi parte.

Saludos,

[faraonDX]

Hola delphius, permiteme decirte que me estás aportando ideas, y te lo agradesco mucho, de todas formas voy a tratar de cambiar la tónica y basarme un poco en ejemplos prácticos:
se desea hacer un sistema para controlar datos en una agencia, de los autos se tiene (ID, modelo , marca).

Según los que veo en este ejemplo hay dos clases que están presentes: TAgencia y TAuto, y la relación que existe entre ellas es la agregación.

Ahora bien en un proyecto en delphi debo utlizar otros elemetos que me aporta el mismo, como el datamodule en el cual se insertan: Conexion,Query, Table , (datasourse). Por lo menos el datamodule genera una clase en una Unit en la que se pueden implementar diferentes métodos.

La realidad a mi modo de ver es, que para este problema si yo quiciera desarrollarlo rápido ignoraría las clases TAgencia y TAuto y realizaría la relación (Dataware - DataSource - Table) y ya resuelvo el problema, pero si he realizado un diseño OO entonces necesito que los controles Dataware hagan uso de los métodos de TAuto (por ejemplo) y A la vez TAuto haga uso de DataModule , que pinta entonces el Datasource.

Puedes ver un ejemplo sencillo y quizas me entiendas un mejor si visitas el articulo que se encuentra: http://www.rinconcitodelphi.com/arti...PenDelphi1.pdf

Espero que entiendas este problema y que aclare las preguntas que me hiciste como:

Empezado por Delphius

¿A que te refieres a que no te gusta el modo en que se relacionan los componetes? Es la manera en que se trabja en Delphi. ¡Los dataware deben estar ligados a las fuentes de datos para funcionar!

Empezado por Delphius

¿A que haces referencia cuando dices en relacion con los elementos de la intefaz de usuario?

En realidad quise decir eso:

Empezado por Delphius

Pero si lo mejor estimada y precisa posible.

Espero que tambien el problema que puse arriba, te explique mis dudas.
y me puedas argumentar un poco ¿Como ese problema se ve involucrado en:?

Empezado por Delphius

----------------------------------------------------------------------
Capa Interfaz:
Zona 1: controles simples - Zona 2: controles dataware
----------------------------------------------------------------------
Capa Lógica:
Zona 1: Tu diseño lógico: Clases - Zona 2: Datasource
----------------------------------------------------------------------
Capa Datos:
Zona 1: Datamodule, xxDataBase, Table, etc...
----------------------------------------------------------------------

Permiteme decirte que en la medida que voy redactando el texto me voy dando cuenta de muchas cosas, creo que casi estoy dando con el clavo.

Disculpa si estoy pidiendo mucho.
Gracias.

[[Delphius]]

Hola, en estos momentos estoy a 185 kms de mi PC, y aquí la conexión deja mucho que desear.

No tengo Delphi. Es que estoy pasando el fin de semana fuera, en familia y mañana es el día del padre (Argentina) y se me hará dificil ver lo que me comentas.

Si puedes esperar hasta el martes o miercoles...
O de última espero que alguien más pueda aportarte mejores respuestas.

Saludos.

[[Delphius]]

O el amigo faraonDX está muy ocupado, o se a asustado por comentarios.

faraonDX, por si lees esto...
Ya me he descargado el pdf y le dí una primera leída entera. El artículo es demasiado breve y deja al final cosas en el aire... pero creo entender lo que buscas.

Igualmente sería muy recomendable que profundices mucho más tus inquietudes. Cuando más certera y descriptiva sea tu pregunta más fácil será canalizar la respuesta.

Dame un tiempo, estoy armando una respuesta. Estoy repasando y reevaluando algunos conceptos y diseño.

Creo que sería más enriquecedor que otros miembros más experimentados ofrezcan también su punto de vista en el asunto. No te cierres a una sola respuesta, sobre todo si es mía.

Saludos,

[faraonDX]

Hola delphius.

Nooo no estoy perdido ni estoy asustado por nada.
Lo que pasa es que estaba esperando alguna respuesta tuya. Permiteme decite que estoy tambien dandole taller al problema y es que soy muy insistente y hasta que no doy con la verdad no estoy tranquilo, he analizado tus respuestas anteriores y estoy desarrollando prototipos de ejemplo. Para ver si aterrizo los conocimientos.

La verdad es que me he estudiando algunos libros referente al tema, que tienen mucha teoría pero una cosa es la teoría y otra es la práctica, llevar un diseño a la implementación requiere de experiencia , pienso yo. Mi problema gira en torno a eso, pués los sistemas que he desarrollado anteriormente lo he realizado de forma estructurada sin tener un diseño OO para otros problemas que no requiere de persistencia no tengo problema. Pero en las bases de datos me choca la relación:
(table - datasource - data-aware) que resuleve el problema sin tener que definir clases y objetos.


Para mi no tiene sentido establecer una relación nueva como:
Table - Tentidad(Objeto definido) - Data-aware, según los principios de diseño la capa de presentación debe comunicarse con la capa lógica y no directamente con la capa de datos(persistencia). Eso lo explicaste bien en comentarios anteriores, pero en este caso se rompe, a mi manera de ver el enlace: (table - datasource - data-aware).

He tratado de ser lo más explicito posible pero ha veces es dificil trasmitir esactamente los que quiero.

Tambien espero que sea probechoso para ti debatir este tema como lo está haciendo para mi, pués si hay algo de lo que aprendo es de los debates.

Saludos de faraonDX.

[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....

[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.