Información de Modelo en 3 Capas. Firebird

[roman]

Empezado por AzidRain

El chiste es separar bien los limites de cada cosa. Una forma, por ejemplo, no debe manipular directamente una tabla, sino hacerlo por medio de alguna otra clase.
Por ejemplo, el catalogo de clientes, puede haber un objeto "TClientes" con sus métodos nuevo, borrar, editar, etc. este objeto clientes es el que internamente accede a datos (aunque aqui adentro ya no utilice mucha OOP, pero el objetivo es encapsular lo mas que se pueda) Este objeto TClientes puede ser una propiedad del Form Catalogo de clientes.

Muy interesante lo que tratan en este hilo. AzidRain, si no es molestia, me gustaría que me aclarases algo: ¿usas o no usas componentes db-aware? Tal como lo planteas, para mantener separados el formulario del acceso a datos, haces la comunicación a través de una clase del tipo TClientes, pero entonces, ¿cómo llenas los controles del formulario que muestran los datos?

// Saludos

[[Delphius]]

Muchas gracias Lepe por aportar ayuda. Ya me va entrelazando y uniendo las cosas en la cabeza.

Empezado por Lepe

Yo usaría herencia visual para el datamodule, para al menos tener algunas propiedades ya asígnadas. Será lógico tener el Datamodule principal (donde reside el TDatabase y TTransaction ya configurados) y los nuevos datamodules tendrán un "enlace" a dichos componentes del Datamodule principal.

Ha tener en cuenta. No se que tan complicado sea hacer mediante las herencias visuales; aunque si suena lógico lo que dices.

Empezado por Roman

Muy interesante lo que tratan en este hilo.

Muchas gracias. Considero que puede ser de mucha información y utilidad para muchos aventurados en POO + DB.

Empezado por Roman

¿usas o no usas componentes db-aware? Tal como lo planteas, para mantener separados el formulario del acceso a datos, haces la comunicación a través de una clase del tipo TClientes, pero entonces, ¿cómo llenas los controles del formulario que muestran los datos?

Ese es uno de los problemas al emplear db-ware... ya que se saltea la capa lógica.
Esa pregunta, a la inversa, es realmente la otra cara de la moneda. Y como lo das a entender debe ser puesta de análisis.

Hay dos canales:
1. Canal Superior: Interfaz/Lógica. Lo que creo que roman hace referencia.
2. Canal Inferior: Lógica/Datos. Este punto es el que se estuvo tratando.

Para la comunicación hacia el exterior yo estaba pensando en algo como:

Código Delphi [-]
TClaseDeSalida = class
   private
      // algo de interés
   public
      // propiedades
     // procedimientos, funciones
     MostrarDatos(info: array of TDatosadecuados {?}; Controles: array of TControl {?}); overload;
    MostrarDatos(Controles: array of TControl); overload;
end;

Mi idea es que haya una clase que reciba los datos y los coloque en los controles pasados por parámetros. No se hasta que punto se podría... habría que ver esta posibilidad.

Voy a hacer un pequeño diagrama de como lo tengo pensado y lo subo a ImageShack y pongo un enlace. Para que se pueda dar una idea.

Saludos,

[[Delphius]]

Hola a todos,
Antes había dicho que iba a realizar un diagrama y lo subía... pero se me está haciendo dificil sentarme frente a la PC porque paso la mayor parte del día fuera. Estoy trabajando como DBA y esto me quita medio día.

En cuanto tenga nuevas novedades sobre este asunto estaré posteando...
Igualmente si alguien más se anima a continuar con el tema, bienvenido sea.

Saludos a todos,

[[AzidRain]]

Contestando la pregunta de Roman..
Si, uso componentes dbaware. Como lo modelo (un poco por las prisas) las ventanas con acceso a algun dato o datos contienen componentes dataware, los cuales se llenan a partir de algun query por ahi. Normalmente cuido que los querys devuelven solo lo necesario.

[faraonDX]

Un saludo tengan todos.

Como te comente al amigo delphius este es exactamente lo que estaba buscando, porque es un tema que tiene tela por donde cortar, anteriormente el análisis yo lo realizaba de una forma estructurada pues determinaba las principales áreas funcionales de sistema a desarrollar e iba subdividiendo el sistema hasta que tuviera cierta estabilidad y poca complejidad, nada de diseño de clases sino procedimientos y funciones que pertenecían a un área funcional, lo cierto es que normalmente lo anterior parece sencillo, la realidad es que en aplicaciones de dimensiones mayores, se forma cierta complejidad que a veces no podemos dominar en toda su dimensión (Análisis –diseño - implementación), desde que me inicie en la programación oí hablar de poo pero no lo entendía del todo , sin saber que esto me podía resolver el problema.

Ahora estoy empeñado en realizar los análisis de mis aplicaciones de una forma OO, perfecto, pero a la hora de llevarlo a implementación es donde surgen los problemas de los que se están comentando en este debate, principalmente en sistemas de bases de datos (SBD).

Si tengo un diseño OO determinado, la implementación debe describirlo, pienso yo.

Como comentaba el amigo delphius en un de sus post:

[quote= delphius]
Creo que el problema pasa por el significado de "3 capas". Yo entiendo por tres capas a esto:

Capa Interfaz
-------------
Capa Lógica
-------------
Capa Datos
[quote]

La interconexión que existe entre estas capas es el dilema a mi entender, el colegaAzidRain explica como modela su sistema y en verdad me aclara muchas dudas, principalmente en la relación entre la capa lógica y la de datos, pero la verdad que no logro entender como interconecto los controles db- aware (capa InterfazU) con la capa lógica, teniendo en cuenta que por defecto existe una relación Table – datasource – dbware.

Auque delphius expone una posible interconexión, la verdad que tendría que probar a ver si funciona.

Yo propongo un ejemplo práctico completo y sencillo en que se pudiese plasmar todas estas teorías, digo si no estoy pidiendo mucho.

Algo así como el artículo: http://www.rinconcitodelphi.com/arti...PenDelphi1.pdf
Que por cierto me parece un poco insustancial. A ver como se resuelve esto con el modelo hibrido de AzidRain.

[faraonDX]

Pido diculpa por el post anterior, parece que tuvo un accidente de transito, la verdad es que tengo una conexión un poco lenta, y el apuro por codificar tare con sigo ese tipo de accidente.