Información de Modelo en 3 Capas. Firebird

[[Delphius]]

Empezado por AzidRain

Actualmente opté por un esquema híbrido, un poco de una cosa en donde se pueda y un poco de la otra donde no se puede. La clave: la documentación de l código.

Disculpa que te moleste AzidRain, ¿Me podrías indicar, si no es demasiada molestia, en forma simple o por lo menos introductoria sobre como realizas este esquema híbrido?

Ten por seguro que llevo un riguroso esquema de documentación de código. Aplico fielmente las buenas prácticas y consejos de la ingeniería de software. Prácticamente he hecho de Ingenía de Software. Un enfoque Práctico de Roger S. Pressman mi biblia.

Desde ya, muchísimas gracias.
Saludos

[[AzidRain]]

Pues bien, aunque no me considero por mucho experto yo lo hago asi para no meterme en honduras:

Practicamente la Capa de datos queda metida en uno o varios datamodules que son los "objetos" que en mi abstraccion saben como manejar los datos que no son mas que tablas.

Ahora bien, todo lo demás lo modelo asi:

1-- Formas "inteligentes"
2.- Formas Auxiliares
3.- Clases varias (todo lo que no sea forma)

Las formas inteligentes saben hacer cosas segun sea el caso, por ejemplo, un catalogo de clientes. La forma es capaz de editar, borrar, etc. uno o varios clientes..para ello utiliza alguno de los datamodules que son los que de verdad hacen el trabajo.

Las formas auxiliares son solo mensajitos o formas adicionales que lo unico que hacen es recoger alguna información (por ejemplo una ventanita de captura).

Las demás clases hacen cosas que no requieren interfaz: respaldos, configuraciones, etc. y pueden formar parte de una forma como propiedad.

De manera que al final lo que obtienes es un conjunto de formas que utilizan otros objetos o clases para manipular datos (la interfaz se da por hecho).

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.

No es muy ortodoxo este esquemita pero a mi me ha funcionado y sobre todo se presta para esos casos en los que no hay mucho tiempo para modelar y hay que programar algo al vuelo.

[[Delphius]]

Gracias por ayudar AzidRain.

Bueno, a ver... si logro unir las cosas siguiendo tu modelo híbrido. Con lo que yo voy armando.

1. Yo tengo varias clases, que operan y se pasan parámetros. Todo lógica, nada de interfaz... Este conjunto forma la capa lógica.
2. En la capa más baja (Datos) está el/los DataModule/s con el Connection, y posibles algunos que otros Tables, Querys, etc

La comunicación entre las clases y la base de datos debe pasar por el DataModule. Eso creo que está claro, al menos así lo entiendo yo. Y dependiendo de las consideraciones, analáisis, etc... se debe hacer un "canal" más o menos estrecho.

Este canal de comunicación está formado por clases que son las que propiamente tienen encapsulada los eventos y/o procedimientos para permitir las operaciones habituales sobre la base de datos:
*Agregar
*Modificar
*Borrar
*Consultar

Por lo tanto estas clases deberán ser las más bajas de la capa.
Hasta aquí llego teóricamente, ahora... en forma práctica... ¿esto se consigue con algo similar a esto?

Código Delphi [-]
TUnaClaseDeInteres = class
  private
     FModulo: TDataModule; // Un apuntador al DataModule al que debe invadir?
     FConsulta: TQuery; // Un Query para armar consultas?
     // O Tal vez indicar como privado componentes especializados. Como los IBX en mi caso...
  public
     // Propiedades
     constructor Create; override;
     destructor Destroy; override;
     // Funciones y/o procedimientos
     function Agregar(InfoInteres: TInfoInteres): algun_tipo_adecuado; 
     function Agregar: algun_tipo_adecuado; overload;
     // Asi... en forma análoga para Modificar, Borrar y/o Consultar
end;

De modo que, si el análisis lo amerita se pueda hacer algo como:

Código Delphi [-]
TUnaClaseHija = class(TUnaClaseDeInteres);
  private
     FAlgodeInteres: tipo;
     //....
  public
    // Otras cosas interesantes? Algo más directo y especializado para un motor en particular talvez?
end;

Ahora, como le indicaría que debe hacer contacto con el datamodule? Allí me lio... Sería conveniente ver la posibilidad de hacer algo como:

Código Delphi [-]
   UnaClaseDeInteres.AsignarModulo(ElDataModuleAdecuado);

Si voy entendiendo bien... o si tienen críticas, serán escuchadas.
Muchas gracias.

[[Lepe]]

El apuntador al TDatamodule viene así:

Código Delphi [-]
property DataModule : TDatamodule read FDatamodule write SetDAtaModule;
....


procedure TXXX.SetDatamodule(Value:TDatamodule);
begin
  if Value <> FDatamodule then
  begin 
    Value := FDatamodule;
    if Assigned(Value) then
    begin
       // ya podemos usar el datamodule
      //  ojito que se puede hacer :
     //   Datamodule := nil; y habrá que tenerlo en cuenta para no traspasar
    //    un nil
    end;
end;

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.

Para asignar el Datamodule que nos interese, pues como siempre se hace en delphi:

Código Delphi [-]
  UnaClaseDeInteres.Datamodule := dmPepito;


// Adicionalmente se podría desconectar la clase del datamodule así:
  UnaClaseDeInteres.Datamodule := nil; // no sé si será de utilidad... pero ahí está.

Saludos

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