Información de Modelo en 3 Capas. Firebird

[maro]

Hola,

Creo que el problema es que lo que pides es algo muy general, ya que el tema puede ser muy extenso.

La programación en 3 capas básicamente consiste en separar el motor de datos, del motor SQL y del software cliente. De esta forma dividimos físicamente los procesos: "mantenimiento de datos", "Consulta y manipulación de datos" e "interface para el usuario".
Cada una de estas capas, puede ser instalada en distintas y diversas máquinas, con intención de agilizar cada uno de los procesos y ofrecer un mayor rendimiento a mayor número de usuarios.


Si necesitas orientación sobre algo más concreto sobre el trabajo en 3 capas (que realmente puede y debe ser >= 3 capas ), sobre motores de datos, componentes, metodología, etc, puedes comentarlo y podremos echarte una mano.

Si lo que quieres es saber como empezar, puede buscar información sobre DbExpress + DataSnap para Delphi.

Por otro lado, si lo que quieres es trabajar con base de datos C/S dentro de una red de área local, no te recomiendo trabajar en 3 Capas, aunque esto realmente depende de la arquitectura del Software que desees desarrollar.

Un Saludo.

[[Delphius]]

Gracias maro por responder y ofrecer tu ayuda.

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

Y vengo llevando desde hace tiempo un enfonque dirigido por POO. Concentré el mayor tiempo de mi análisis al aspecto Lógico. La idea es que conseguir un conjunto de clases que puedan ser reutilizadas. Tengo dos grupos de clases: las de "propódito general" y "propias del negocio" Esto me favorece a que pueda ampliar ambos grupos de clases en forma más o menos independiente.

Con respecto al motor de base de datos que empleo es Firebird versión 1.5.3.

Por el momento lo estoy manejando localmente y estoy pensando en como darle un enfoque C/S. No creo que haya demasiado problemas en esto... aunque reconozco que no se si deberé cambiar y alterar en algún punto el aspecto lógico (mis clases).

Lo que me está costando... entender y comprender es unir las diversas ideas y conceptos que tengo sobre 3 capas, POO y Arquitectura C/S. Como dije antes, intenté ofrecer ayuda aquí y el problema sigue en nieblas.
Buscando, y buscando encontré algo, pero lo que ofrece sobre ser 3 capas me es un concepto ajeno, ya que no coincide mi interpretación de lo que significa 3 capas con lo expresado en dicho documento.

Si alguien tiene un documento y/o un link que trate estos aspectos que complementen a lo que se puede leer en la Cara Oculta se los agradecería. Un enfoque C/S no es primordial, pero si tratar de seguir llevando un enfoque OO y la comunicación sobre base de datos. Esto no sólo me serviría para mi, sino también para FaraonDX y otros interesados.

Espero que se me entienda.
Muchas gracias por tomarse el tiempo en leer este post.
Saludos,

[[AzidRain]]

A mi me paso lo siguiente:

Empecé con POO cuando Delphi se llamaba Borland Pascal 6.0 y luego 7.0. y aquella maravillosa cosa llamada Turbo Vision.

QUe maravilla, me movia con soltura en la creación de aplicaciones usando solo OOP, hasta que un día...

Me encontré con el mundo de las bases de datos y las aplicaciones C/S. Lo peor llegó al empezar a estudiar el modelo Entidad-Relación...

E-S y POO simplemente son dos cosas diferentes, si quieres aplicar una deshaces la otra. Ahi fue mi calvario, muchos de mis programas terminaron funcionando bien por fuera pero por dentro llenos de chapuzas y cosas raras. Después descubrí que había cosas como ECO que hacen la traducción de E-S a POO pero eso implicaba ponerse a leer mas y mas y terminar con aplicaciones que con tal de mantener las capas y lo de la POO se llenaban de líneas y líneas de código.

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.

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

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