Clases Maestro Detalle

[NickName]

Hola...

Primero que nada q tengan una feliz navidad...

Sucede que decidí incursionar un poco en la programación orientada a objetos… Estoy desarrollando un proyecto donde tengo mis formas y uso métodos de clases creadas… Tengo una clase Conexión y mis clases de Clientes, Proveedores etc. heredan de esa clase les pongo el código de mi clase proveedor… Todas las demas clases son identicas...

Código Delphi [-]
unit C_Proveedores;

interface

Uses C_Conexion, Db, SysUtils;

Type
    TProveedores = class(TConexion)
  private
    FNombre_Proveedor: string;
    FCod_Proveedor: integer;
    FPagina_Web: string;
    FColonia: string;
    FFax: string;
    FCalle: string;
    FCiudad: string;
    FEstado: string;
    FCodigo_Postal: string;
    procedure SetCodigo_Postal(const Value: string);
    procedure SetCalle(const Value: string);
    procedure SetCiudad(const Value: string);
    procedure SetCod_Proveedor(const Value: integer);
    procedure SetColonia(const Value: string);
    procedure SetEstado(const Value: string);
    procedure SetFax(const Value: string);
    procedure SetNombre_Proveedor(const Value: string);
    procedure SetPagina_Web(const Value: string);

    Published
       Property Cod_Proveedor:integer read FCod_Proveedor write SetCod_Proveedor;
       Property Nombre_Proveedor:string read FNombre_Proveedor write SetNombre_Proveedor;
       Property Estado:string read FEstado write SetEstado;
       Property Ciudad:string read FCiudad write SetCiudad;
       Property Colonia:string read FColonia write SetColonia;
       Property Calle:string read FCalle write SetCalle;
       Property Codigo_Postal:string read FCodigo_Postal write SetCodigo_Postal;
       Property Fax:string read FFax write SetFax;
       Property Pagina_Web:string read FPagina_Web write SetPagina_Web;
{$REGION '   Metodos...'}
       Function Insertar_Proveedor:Boolean;
       Function Modificar_Proveedor:Boolean;
       Function Eliminar_Proveedor:Boolean;
       Function Traer_Proveedores:TDataSource;
{$ENDREGION}
    end;
implementation

{ TProveedores }

function TProveedores.Eliminar_Proveedor: Boolean;
begin
    With Operacion Do
    Begin
         SQL.Clear;
         SQL.Add('Delete From Proveedores' +
                 ' Where Cod_Proveedor = :Old_Cod_Proveedor');
         ParamByName('Old_Cod_Proveedor').AsInteger:=Cod_Proveedor;
         //---- Iniciar transa
         Transaccion.StartTransaction;
         Prepare;
         Try
              ExecQuery;
         Except on E:Exception do
         Begin
              Transaccion.Rollback;
              Raise;
              Exit;
         End; // execept
         End; // Try
    End;  // With

    Transaccion.Commit;
    Result:=True;
end;

function TProveedores.Insertar_Proveedor: Boolean;
begin
    With Operacion Do
    Begin
         SQL.Clear;
         SQL.Add('Insert Into Proveedores(Nombre_Proveedor, Estado, Ciudad, Colonia, Calle, Codigo_Postal, Fax, Pagina_Web)' +
                 'Values(:Nombre_Proveedor, :Estado, :Ciudad, :Colonia, :Calle, :Codigo_Postal, :Fax, :Pagina_Web)');
         ParamByName('Nombre_Proveedor').AsString:=Nombre_Proveedor;
         ParamByName('Estado').AsString:=Estado;
         ParamByName('Ciudad').AsString:=Ciudad;
         ParamByName('Colonia').AsString:=Colonia;
         ParamByName('Calle').AsString:=Calle;
         ParamByName('Codigo_postal').AsString:=Codigo_Postal;
         ParamByName('Fax').AsString:=Fax;
         ParamByName('Pagina_Web').AsString:=Pagina_Web;
         //---- Iniciar transa
         Transaccion.StartTransaction;
         Prepare;
         Try
              ExecQuery;
         Except on E:Exception do
         Begin
              Transaccion.Rollback;
              Raise;
              Exit;
         End; // execept
         End; // Try
    End;  // With
    Transaccion.Commit;
    Result:=True;
end;

function TProveedores.Modificar_Proveedor: Boolean;
begin
    With Operacion Do
    Begin
         SQL.Clear;
         SQL.Add('Update Proveedores Set Nombre_Proveedor = :Nombre_Proveedor, Estado = :Estado, Ciudad = :Ciudad, Colonia = :Colonia, Calle = :Calle, Codigo_Postal = :Codigo_Postal, Fax = :Fax, Pagina_Web = :Pagina_Web' +
                 ' Where Cod_Proveedor = :Old_Cod_Proveedor');
         ParamByName('Old_Cod_Proveedor').AsInteger:=Cod_Proveedor;
         ParamByName('Nombre_Proveedor').AsString:=Nombre_Proveedor;
         ParamByName('Estado').AsString:=Estado;
         ParamByName('Ciudad').AsString:=Ciudad;
         ParamByName('Colonia').AsString:=Colonia;
         ParamByName('Calle').AsString:=Calle;
         ParamByName('Codigo_postal').AsString:=Codigo_Postal;
         ParamByName('Fax').AsString:=Fax;
         ParamByName('Pagina_Web').AsString:=Pagina_Web;
         //---- Iniciar transa
         Transaccion.StartTransaction;
         Prepare;
         Try
              ExecQuery;
         Except on E:Exception do
         Begin
              Transaccion.Rollback;
              Raise;
              Exit;
         End; // execept
         End; // Try
    End;  // With

    Transaccion.Commit;
    Result:=True;
end;

procedure TProveedores.SetCalle(const Value: string);
begin
  FCalle := Value;
end;

procedure TProveedores.SetCiudad(const Value: string);
begin
  FCiudad := Value;
end;

procedure TProveedores.SetCodigo_Postal(const Value: string);
begin
  FCodigo_Postal := Value;
end;

procedure TProveedores.SetCod_Proveedor(const Value: integer);
begin
  FCod_Proveedor := Value;
end;

procedure TProveedores.SetColonia(const Value: string);
begin
  FColonia := Value;
end;

procedure TProveedores.SetEstado(const Value: string);
begin
  FEstado := Value;
end;

procedure TProveedores.SetFax(const Value: string);
begin
  FFax := Value;
end;

procedure TProveedores.SetNombre_Proveedor(const Value: string);
begin
  FNombre_Proveedor := Value;
end;

procedure TProveedores.SetPagina_Web(const Value: string);
begin
  FPagina_Web := Value;
end;

function TProveedores.Traer_Proveedores: TDataSource;
begin
    Consulta.Close;
    Consulta.SQLs.SelectSQL.Clear;
    Consulta.SQLs.SelectSQL.Add('Select * From Proveedores ');
    try
        Consulta.Open;
    except on E: Exception do
    begin
        Raise;
        Exit;
    end;
    end;
    Result:= TDataSource.Create(Nil);
    Result.DataSet:=Consulta;
end;

end.

Me gustaría que checaran el código y me dijeran si la forma de hacerlo es la correcta… ya que no tengo experiencia en esto...

Pero lo que me esta deteniendo con el desarrollo es como se harían las clases de Maestro detalle por ejemplo tengo Mis Clases Movimientos que contiene los movimientos que se hacen en el almacén pero cada movimiento puede tener varios Productos en la clase Detalle_Movimiento estas 2 clases se comunican con las tablas de la Db. que son Movimientos y Detalle_Movimiento les pongo lo que tengo para ver si alguien me puede iluminar un poco y decirme como puedo hacer para ir guardando los productos en la clase Detalle_Movimiento o si solo tengo que hacer una sola clase es la primera vez que estoy haciendo esto y la verdad no se como se hace… declaro Propiedades de tipo Arrays …? En la clase Movimiento o fuera de ella uso listas…?
Clase Movimeinto

Código Delphi [-]
unit C_Movimientos;

interface
Uses C_Conexion, Db, SysUtils, C_Detalle_Movimiento;
Type
 TMovimientos = class(TConexion)
  private
    FNumero_Partidas: Integer;
    FTotal: Integer;
    FCod_Movimiento: Integer;
    FObs_Movimiento: String;
    FNumero_Piezas: Integer;
    FCod_Tipo_Movimiento: String;
    FProductos: TDetalle_Movimiento;
    procedure SetProductos(const Value: TDetalle_Movimiento);
    procedure SetCod_Movimiento(const Value: Integer);
    procedure SetCod_Tipo_Movimiento(const Value: String);
    procedure SetNumero_Partidas(const Value: Integer);
    procedure SetNumero_Piezas(const Value: Integer);
    procedure SetObs_Movimiento(const Value: String);
    procedure SetTotal(const Value: Integer);
  Public
    constructor Create;
  Published
    Property Cod_Movimiento:Integer read FCod_Movimiento write SetCod_Movimiento;
    Property Cod_Tipo_Movimiento:String read FCod_Tipo_Movimiento write SetCod_Tipo_Movimiento;
    Property Numero_Partidas:Integer read FNumero_Partidas write SetNumero_Partidas;
    Property Numero_Piezas:Integer read FNumero_Piezas write SetNumero_Piezas;
    Property Total: Integer read FTotal write SetTotal;
    Property Productos:TDetalle_Movimiento read FProductos write SetProductos;
    Property Obs_Movimiento:String read FObs_Movimiento write SetObs_Movimiento;
      {$REGION 'Mis Metodos '}

      Function Insertar_Movimiento:Boolean;
      Function Eliminar_Movimiento:Boolean;
      Function Modificar_Movimiento:Boolean;
      Function Traer_Movimientos:TDataSource;
      {$ENDREGION}
 end;

implementation

{ TMovimientos }

constructor TMovimientos.Create;
begin
    Productos:=TDetalle_Movimiento.Create;
end;

function TMovimientos.Eliminar_Movimiento: Boolean;
begin
    With Operacion Do
    Begin
         SQL.Clear;
         SQL.Add('Delete From Movimientos' +
                 ' Where Cod_Movimiento = :Old_Cod_Movimiento');
         ParamByName('Old_Cod_Movimiento').AsInteger:=Cod_Movimiento;
         //---- Iniciar transa
         Transaccion.StartTransaction;
         Prepare;
         Try
              ExecQuery;
         Except on E:Exception do
         Begin
              Transaccion.Rollback;
              Raise;
              Exit;
         End; // execept
         End; // Try
    End;  // With

    Transaccion.Commit;
    Result:=True;
end;

function TMovimientos.Insertar_Movimiento: Boolean;
begin

end;

function TMovimientos.Modificar_Movimiento: Boolean;
begin

end;

procedure TMovimientos.SetCod_Movimiento(const Value: Integer);
begin
  FCod_Movimiento := Value;
end;

procedure TMovimientos.SetCod_Tipo_Movimiento(const Value: String);
begin
  FCod_Tipo_Movimiento := Value;
end;

procedure TMovimientos.SetNumero_Partidas(const Value: Integer);
begin
  FNumero_Partidas := Value;
end;

procedure TMovimientos.SetNumero_Piezas(const Value: Integer);
begin
  FNumero_Piezas := Value;
end;

procedure TMovimientos.SetObs_Movimiento(const Value: String);
begin
  FObs_Movimiento := Value;
end;

procedure TMovimientos.SetProductos(const Value: TDetalle_Movimiento);
begin
  FProductos := Value;
end;

procedure TMovimientos.SetTotal(const Value: Integer);
begin
  FTotal := Value;
end;

function TMovimientos.Traer_Movimientos: TDataSource;
begin
    Consulta.Close;
    Consulta.SQLs.SelectSQL.Clear;
    Consulta.SQLs.SelectSQL.Add('Select * From Movimientos');
    try
        Consulta.Open;
    except on E: Exception do
    begin
        Raise;
        Exit;
    end;
    end;
    Result:= TDataSource.Create(Nil);
    Result.DataSet:=Consulta;
end;

end.

Clase Detalle_Movimeinto

Código Delphi [-]
unit C_Detalle_Movimiento;

interface
Uses C_Conexion, Db, SysUtils;
Type
  TDetalle_Movimiento = class(TConexion)
  private
    FCodigo_Barras: string;
    FImporte: Currency;
    FCod_Movimiento: Integer;
    FP_Unitario: Currency;
    FCantidad: Integer;
    FCod_Detalle_Movimiento: Integer;
    procedure SetCantidad(const Value: Integer);
    procedure SetCod_Detalle_Movimiento(const Value: Integer);
    procedure SetCod_Movimiento(const Value: Integer);
    procedure SetCodigo_Barras(const Value: string);
    procedure SetImporte(const Value: Currency);
    procedure SetP_Unitario(const Value: Currency);
    Published
     Property Cod_Detalle_Movimiento:Integer read FCod_Detalle_Movimiento write SetCod_Detalle_Movimiento;
     Property Cod_Movimiento:Integer read FCod_Movimiento write SetCod_Movimiento;
     Property Codigo_Barras:string read FCodigo_Barras write SetCodigo_Barras;
     Property Cantidad:Integer read FCantidad write SetCantidad;
     Property P_Unitario:Currency read FP_Unitario write SetP_Unitario;
     Property Importe:Currency read FImporte write SetImporte;
      {$REGION 'Mis Metodos '}
      Function Insertar_Detalle_Movimiento:Boolean;
      Function Eliminar_Detalle_Movimiento:Boolean;
      Function Modificar_Detalle_Movimiento:Boolean;
      Function Traer_Detalle_Movimientos:TDataSource;
      {$ENDREGION}
  end;
implementation

{ TDetalle_Movimiento }

function TDetalle_Movimiento.Eliminar_Detalle_Movimiento: Boolean;
begin

end;

function TDetalle_Movimiento.Insertar_Detalle_Movimiento: Boolean;
begin

end;

function TDetalle_Movimiento.Modificar_Detalle_Movimiento: Boolean;
begin

end;

procedure TDetalle_Movimiento.SetCantidad(const Value: Integer);
begin
  FCantidad := Value;
end;

procedure TDetalle_Movimiento.SetCodigo_Barras(const Value: string);
begin
  FCodigo_Barras := Value;
end;

procedure TDetalle_Movimiento.SetCod_Detalle_Movimiento(const Value: Integer);
begin
  FCod_Detalle_Movimiento := Value;
end;

procedure TDetalle_Movimiento.SetCod_Movimiento(const Value: Integer);
begin
  FCod_Movimiento := Value;
end;

procedure TDetalle_Movimiento.SetImporte(const Value: Currency);
begin
  FImporte := Value;
end;

procedure TDetalle_Movimiento.SetP_Unitario(const Value: Currency);
begin
  FP_Unitario := Value;
end;

function TDetalle_Movimiento.Traer_Detalle_Movimientos: TDataSource;
begin

end;

end.

Ojala y alguien me pueda ayudar me siento perdido...

[axesys]

Esto te puede facilitar la creación de las clases y su mapeo en una base de datos:

http://dn.codegear.com/es/article/36846

[NickName]

Hola Axesys Gracias por contestar...

Bueno ya habia visto un poco esa tecnologia Eco para mi es fantastica lo malo es que mi proyecto lo estoy desarrollando con Delphi para win32 y creo que no lo puedo usar solo que fuera el delphi para .net...

No se que me aconsejas voy a tratar de hacer un ejemplo con el eco de lo que quiero hacer y de hay haber si puedo encontrar la estructura de las clases para copiar lo que necesito y seguir con mi proyecto... bueno haber si encuentro la estructura que quiero... o mas bien la forma en como estan diseñadas las clases...

Gracias...

[NickName]

Hola no se como dije que probaria si no tengo la versión de Delphi .Net solo tengo Delphi para win32 y con esa no se puede... ojala y alguien mas pueda ayudar un poco...

[[Delphius]]

Hola NickName,
Disculpa, pero no puedo darme el lujo de estar probando tu código... la verdad es que el tiempo en estos momentos son demasiados acotados...
Por el vistazo que le dí habría que definir mejor el concepto y entendimiento de lo que es realmente el concepto de "Maestro/Detalle" en POO. Se que dices que te estás iniciando en el mundo de la POO. Te aconsejo que para seguir en este mundo de la POO agarres un buen plano: UML. Te recomiendo el libro UML y Patrones de Craig Larman y/o UML Gota a Gota de Martin Flower y Kendall Scott.

Si ya sabes algo de UML sabrás que todo deriva de un diseño del dominio. Un ejemplo sencillo, de lo que comprendo y entiendo del problema que redactas, es este (disculpa por lo burdo):

Proveedor - 1 ------- 1..* - Movimientos - 1 -------------------- 1..* -  LineasMovimientos 
              realiza                        Esta-conformado-por

Más o menos la idea es que: el Proveedor realiza al menos un movimiento y cada movimiento está conformado por una serie de lineas (el detalle).

Generalmente, (no siempre) este manejo de la cardinalidad se consigue con la implementación de un objeto contenedor (como menciona Craig), posiblemente un TObjectList.
La idea de la cardinalidad (el 1-Muchos) y de este ObjectList es mantener en memoria la relación entre cada proveedor y sus movimientos.

De modo que ha simple diseño (y sobre todo rápido) yo lo veo así:

Código Delphi [-]
TProveedor = class
private
   //....
   FMovimientos = TObjectList;
   //....
public
   //....
end;

O si el diseño lo amerita... hacer esto:

Código Delphi [-]
TProveedor = class
private
   //...
  FMovimientos = TMovimiento
public
   //....
end;

Siendo ya, en este caso, TMovimiento descendiente de TObjectList pero que contiene los elementos necesarios y adecuados; ocultando (preferiblemente) la arquitectura de su descendiente (es decir que es posible que sería conveniente que a los fines de uso de esta clase, que oculte al exterior el hecho de que internamente es un TObjectList).

Código Delphi [-]
TMovimiento = class(TobjectList)
private
   //...
public
  //...
end;

Y este procedimiento se realiza en forma análoga entre Movimiento y su detalle.

Por otro lado, no me convence la idea de que las clases lógicas invadan o contengan funciones que podrían (nota la palabra: podrían) recaer en la capa de datos. Es decir que estas clases deleguen el trabajo de hacer la consulta y el acceso a la base de datos a otro objeto que posiblemente esté más calificado.
La idea de delegar este trabajo es que tanto TProveedor, como TMovimiento envien el mensaje de grabar, modificar, borrar, etc a este objeto y sea éste el encargado de hacer el trabajo sucio.

¿Porqué dije podría? Porque si tu diseño (mejor dicho el dominio) es simple es posible que adosar esta nueva clase (llamemosla AccesoDB) haga más complicado al modelo y lleve a costos y pérdida de tiempo.
Creo que resulta lógico pensar que si son estas tres clases (Proveedor, Movimiento, LineaMovimiento) las únicas en el dominio... incorporar esta cuarta... sería un poco lioso y molesto... pero cuando el diseño engloba a más... es claro y evidente de que se necesita un mejor diseño de las clases y su delegación de funciones.

El diseño de tus clases debería seguir el flujo de la información que te proporciona el modelo. El punto de partida de la cardinalidad que yo te he mostrado es tan sólo uno de los puntos a tener en cuenta.
Teniendo en cuenta esto yo estaría pensando en métodos como:

GetMovimientos(): que se encargaría de obtener los movimientos para un proveedor. La clase Proveedor envíea este mensaje a la clase Movimiento. Y a su vez, este nombre sugiere que el proceso sea análogo para sus detalles: GetDetalleMovimientos() o getLineaMovimientos()
InsertarMovimientos(): que al parecer, a mi modo de ver, sería el Proveedor que envía el mensaje... aprovechando el hecho de que está el TObjectList lo que podría realizar es hacer por ejemplo un Add sobre su FMovimiento...

Código Delphi [-]
procedure TProveedor.InsertarMovimiento(Movimiento: TMovimiento);
begin
  ...
  FMovimientos.Add(Movimiento);
  ...
end;

En fin... esto dependerá de como estructures y diseñes tus clases. Como te decía... hay varias posibilidades de como lograr hacer los "vinculos".

Y asi seguiría con el diseño.

Se que no te he ayudado con el código pero al menos creo haber dicho que algo deberías tener en cuenta: La correcta asignación de responsabilidades.

No es que lo que hayas hecho esté mal...sino que no veo como logras hacer referencia entre la clase proveedor y la clase movimientos. No veo, al menos yo, un vinculo de interés (o como debe decirse: asignación de responsabilidades).
Para una primera aproximación, tu diseño ha sido un gran avance.

Si realmente deseas llevar un sentido más "purista" hacia la POO, considero tomes bien estas palabras: leer un buen libro de UML y perder el miedo al análisis y diseño primero.

Y ten presente que no hay un único diseño y comprención del problema. Existen tantos diagramas de dominio, como personas hay en este mundo... por lo que no existe una única solución de como implementar correctamente la asignación de responsabilidades de las clases. De modo que para poder recibir la mejor ayuda sería oportuno que tu nos informes de tu modelo, de tu comprensión del dominio. Porque si yo te muestro mi diseño es posible que no sea tan coincidente con el tuyo y para ti sea más complicado de asimilarlo y comprenderlo.

Espero haber sido de ayuda.
Saludos,

PD: Disculpa por tanto texto.

[axesys]

Para Win32 puedes usar InstantObjects

http://sourceforge.net/project/showf...group_id=94747

Checate el video de intro


Saludos

[NickName]

Hola Delphius...

Primero que nada muchas gracias por toda tu aportación de verdad te agradesco mucho...

Disculpa, pero no puedo darme el lujo de estar probando tu código

Solo queria que me comentaran si no estaba mal la forma de haserlo asi como lo hisite muchas gracias tambien por eso ya que para uno que inicia siempre hay temor de si se esta haciendo lo correcto o no...

Más o menos la idea es que: el Proveedor realiza al menos un movimiento y cada movimiento está conformado por una serie de lineas (el detalle).

Creo que no me explique bien pero mi problema es mas simple que eso ya que no se como podria ser la estructura de las clases Movimiento y Detalle_Movimiento ya que estas son Maestro Detalle la clase de Proveedores solo la puse para que me comentaran si era correcto lo que estaba haciendo pero no tiene ninguna relación con la clase de Movimiento...

La idea de delegar este trabajo es que tanto TProveedor, como TMovimiento envien el mensaje de grabar, modificar, borrar, etc a este objeto y sea éste el encargado de hacer el trabajo sucio.

¿Porqué dije podría? Porque si tu diseño (mejor dicho el dominio) es simple es posible que adosar esta nueva clase (llamemosla AccesoDB) haga más complicado al modelo y lleve a costos y pérdida de tiempo.

Esactamente eso queria que me comentaran por eso puse el codigo de la clase de proveedor... si tengo una clase se llama Conexion y Todas las demas heredan de esa para poder insertar modificar o eliminar datos pero ese es el problema que no sabia si es correcta la implementación te pongo el codigo:

Uso los Fibplus para conectarme a Firebird: Por todo lo que comentas y otro hilo que cheque hasta me da pena publicar mi codigo...

Código Delphi [-]
unit C_Conexion;

interface

Uses Db, SysUtils, pFIBDatabase, pFIBQuery, pFIBDataSet, C_Parametros;

 Type
    TConexion = Class (TObject)
       private
            FDb_Firebird: TpFIBDatabase;
            FConectado: Boolean;
            FParametros: TParametros;
            FConsulta: TpFIBDataSet;
            FTransaccion: TpFIBTransaction;
            FOperacion: TpFIBQuery;
            FUsuario_Conectado: String;
            FDatos_Guardados: Boolean;
            FTarea: String;
            FOtros_Datos: TpFIBDataSet;
            FError_Valida: String;
            procedure SetError_Valida(const Value: String);
            procedure SetOtros_Datos(const Value: TpFIBDataSet);
            procedure SetDatos_Guardados(const Value: Boolean);
            procedure SetTarea(const Value: String);
            procedure SetUsuario_Conectado(const Value: String);
            procedure SetOperacion(const Value: TpFIBQuery);
            procedure SetTransaccion(const Value: TpFIBTransaction);
            procedure SetParametros(const Value: TParametros);
            procedure SetConsulta(const Value: TpFIBDataSet);
            procedure SetConectado(const Value: Boolean);
            procedure SetDb_Firebird(const Value: TpFIBDatabase);
       public
            constructor Create;
            Procedure Conectar_Db_Firebird;
            Function  Identificar(Clave:String):String;
            Function  Traer_Datos(Select:String):TDataSource;
            Function  Validar_Datos:Boolean;  Virtual;
       Published
            Property  Db_Firebird:TpFIBDatabase read FDb_Firebird write SetDb_Firebird;
            Property  Parametros:TParametros read FParametros write SetParametros;
            Property  Conectado:Boolean read FConectado write SetConectado;
            Property  Consulta:TpFIBDataSet read FConsulta write SetConsulta;
            Property  Otros_Datos:TpFIBDataSet read FOtros_Datos write SetOtros_Datos;
            Property  Transaccion:TpFIBTransaction read FTransaccion write SetTransaccion;
            Property  Operacion: TpFIBQuery read FOperacion write SetOperacion;
            Property  Usuario_Conectado:String read FUsuario_Conectado write SetUsuario_Conectado;
            Property  Datos_Guardados:Boolean read FDatos_Guardados write SetDatos_Guardados;
            Property  Tarea:String read FTarea write SetTarea;
            Property  Error_Valida:String read FError_Valida write SetError_Valida;
     end;

implementation

uses FIBDatabase, FIBDataSet;

{ TConeccion }

constructor TConexion.Create;
begin
    Transaccion:= TpFIBTransaction.Create(Nil);
    //---- Crear Objeto Db
    Db_Firebird:= TpFIBDatabase.Create(Nil);
    //---- Inicializa Parametros Db --
    Parametros:= TParametros.Create;
    Db_Firebird.Connected:=False;
    Conectar_Db_Firebird;
    Operacion:= TpFIBQuery.Create(Nil);
    Operacion.Database:=Db_Firebird;
    Consulta:= TpFIBDataSet.Create(Nil);
    Consulta.Database:=Db_Firebird;
    Otros_Datos:= TpFIBDataSet.Create(Nil);
    Otros_Datos.Database:=Db_Firebird;

end;


function TConexion.Identificar(Clave: String): String;
begin
    With Consulta Do
    Begin
         Close;
         SQLs.SelectSQL.Clear;
         SQLs.SelectSQL.Add('Select Nombre_Usuario, Tipo_Usuario, Activo From Usuarios' +
                 ' Where Clave = :Clave');
         ParamByName('Clave').AsString:=Clave;
         //---- Iniciar transa
         Prepare;
         Try
              Open;
         Except on E:Exception do
         Begin
              Raise;
              Exit;
         End; // execept
         End; // Try
    End;  // With
    if Consulta.IsEmpty then
       Result:=''
    else
       begin
           if Consulta.FieldByName('Activo').AsString = 'SI' then
             begin
                  Usuario_Conectado:=Consulta.FieldByName('Nombre_Usuario').AsString;
                  Result:=Consulta.FieldByName('Tipo_Usuario').AsString;
             end
           else
             Result:='INACTIVO';
       end;
end;

Procedure TConexion.Conectar_Db_Firebird;
begin
    //--- Obtener parametros
    //--- Fijar parametros Transaccion --
    Transaccion.TRParams.Add('write nowait rec_version read_committed');

    Transaccion.DefaultDatabase:=Db_Firebird;

    //--- Parametros de la base de datos
    Db_Firebird.SQLDialect:=3;
    Db_Firebird.DatabaseName:=Parametros.Nombre_Db;
    Db_Firebird.ConnectParams.UserName:=Parametros.Usuario;
    Db_Firebird.ConnectParams.Password:=Parametros.Clave;
    Db_Firebird.ConnectParams.CharSet:=Parametros.Caracteres;
    //---- Asigno la Transaccion
    Db_Firebird.DefaultTransaction:=Transaccion;
    Db_Firebird.DefaultUpdateTransaction:=Transaccion;

    try
        Db_Firebird.Connected:=True;
    except on E: Exception do
    begin
        Conectado:=False;
        Raise;
        Exit;
    end;
    end;
    Conectado:= True;
end;

procedure TConexion.SetConectado(const Value: Boolean);
begin
  FConectado := Value;
end;

procedure TConexion.SetConsulta(const Value: TpFIBDataSet);
begin
    FConsulta:=Value;
end;

procedure TConexion.SetDatos_Guardados(const Value: Boolean);
begin
  FDatos_Guardados := Value;
end;

procedure TConexion.SetDb_Firebird(const Value: TpFIBDatabase);
begin
  FDb_Firebird := Value;
end;

procedure TConexion.SetError_Valida(const Value: String);
begin
  FError_Valida := Value;
end;

procedure TConexion.SetOperacion(const Value: TpFIBQuery);
begin
  FOperacion := Value;
end;

procedure TConexion.SetOtros_Datos(const Value: TpFIBDataSet);
begin
  FOtros_Datos := Value;
end;

procedure TConexion.SetParametros(const Value: TParametros);
begin
  FParametros := Value;
end;

procedure TConexion.SetTarea(const Value: String);
begin
  FTarea := Value;
end;

procedure TConexion.SetTransaccion(const Value: TpFIBTransaction);
begin
  FTransaccion := Value;
end;

procedure TConexion.SetUsuario_Conectado(const Value: String);
begin
  FUsuario_Conectado := Value;
end;

function TConexion.Traer_Datos(Select: String): TDataSource;
begin
    Otros_Datos.Close;
    Otros_Datos.SQLs.SelectSQL.Clear;
    Otros_Datos.SQLs.SelectSQL.Add(Select);
    try
        Otros_Datos.Open;
    except on E: Exception do
    begin
        Raise;
        Exit;
    end;
    end;
    Result:= TDataSource.Create(Nil);
    Result.DataSet:=Otros_Datos;
end;

function TConexion.Validar_Datos: Boolean;
begin
    Result:=True;
end;

end.

en un hilo que cheque comentan que los atributos privados de una clase se deben de usar en la misma clase y los publicos desde fuera y mi clase no aplica eso...

En fin... esto dependerá de como estructures y diseñes tus clases. Como te decía... hay varias posibilidades de como lograr hacer los "vinculos".

Pues ese es el punto que no se como estructurar mis clases nunca habia trabajado con objetos... los libros que me recomendaste te prometo leerlos pero como tu dices no hay mucho tiempo y mi proyecto lo tengo que entregar en febrero...

Se que no te he ayudado con el código pero al menos creo haber dicho que algo deberías tener en cuenta: La correcta asignación de responsabilidades.

Creo que si ya habia visto eso del TObjectList lo malo es que uno como novato nunca sabe si es una sola clase y donde pondria la propiedad de ese tipo

No es que lo que hayas hecho esté mal...sino que no veo como logras hacer referencia entre la clase proveedor y la clase movimientos. No veo, al menos yo, un vinculo de interés (o como debe decirse: asignación de responsabilidades).
Para una primera aproximación, tu diseño ha sido un gran avance.

Gracias esto da animos y quiere decir que no voy tan mal....

Y ten presente que no hay un único diseño y comprención del problema. Existen tantos diagramas de dominio, como personas hay en este mundo... por lo que no existe una única solución de como implementar correctamente la asignación de responsabilidades de las clases. De modo que para poder recibir la mejor ayuda sería oportuno que tu nos informes de tu modelo, de tu comprensión del dominio. Porque si yo te muestro mi diseño es posible que no sea tan coincidente con el tuyo y para ti sea más complicado de asimilarlo y comprenderlo.

Por Responsabilidades voy a entender que es la relación que hay de una clase con otra...

Por otro lado creo que mi modelo es simple:
segun yo tengo mi clase Conexion con esta me conecto a la DB... y todas mis demas clases heredan de esta para Insertar Modificar y Eliminar Datos.. lo demas es comun Movimeintos con su Detalle_Movimiento, Ticket y su Detalle_Ticket pero la verdad no tengo nada diseñado como dises solo la idea de acuerdo a la Db que tengo y mi problema es q no se como estructurar esas clases Maestro Detalle... bueno y siendo realistas creo que me falta mucho que aprender....
Por todo Gracias...

[NickName]

Gracias Axesys checare esa opción.... y les comento....

[[Delphius]]

Hola NickName,
De curiosidad he vuelto para ver si respondías.

Me alegro que tengas en cuenta mis comentarios y que estés abierto a alternativas. No tengo Delphi a mano... pero al ver la forma en que tu haz hecho tu diseño, no lo veo correcto.

A mi modo de ver... no tiene sentido lógico que las clases Proveedor, Movimiento, etc hereden de Conexion.

Veamos si me explico: la asignación de responsabilidades es un juego sencillo. Al igual que en la realidad a uno le toca a hacer lo que sabe haber. Y claro está, si lo saber hacer es porque tiene la información para saber hacer su tarea. En POO esto se traduce: un objeto hace algo con la información que este tiene.
Un objeto que no sabe delimitar sus funciones y/o delegar parte de su trabajo a otro objeto tiene problemas de diseño. Y es aqui parte del problema. Una clase Movimiento debería delegar parte de su trabajo hacia la clase LineaMovimiento. Es como querer asignarle todo el trabajo de oficina a una persona.

Parte del problema se soluciona teniendo un ObjectList como te comentaba:

Código Delphi [-]
TMovimiento = class
  private
    FLineasMovimiento = TObjectList;
    { FLineasMovimiento es un contenedor. Contendrá todos los objetos
      de tipo TLineaDeMovimiento.
      Con esto se consigue que un Movimiento conozca sus respectivos
      detalles }
  public
     //...
  end;

Ahora continuando con el planteo. ¿Quien se encargaría de crear cada detalle del movimiento? O dicho de otro modo: ¿Que clase tiene la información necesaria para crear cada LineaMovimiento? Comprendiendo el modelo ("Un Movimiento está compuesto por al menos una Linea de detalle") podemos afirmar que la clase Movimiento es una excelente candidata.
Por lo que dicha clase debe contar con un método que realize esta operación. Por ejemplo:

Código Delphi [-]
procecure TMovimiento.CrearLineaMovimiento(...);
// Posiblemente sea aqui donde se pasan algunos valores iniciales
var Linea: TLineaDeMovimiento;
begin
  Linea := TLineaDeMovimiento.Create;
  //...
end;

¿Terminamos? No... Bueno... ya se ha conseguido hacer parte de la referencia... Hemos creado una linea, pero claro... aqui no termina la historia. ¿Cómo mantenemos la referencia? ¡FLineaMovimiento al rescate!

Una vez que se crea la linea de movimiento (y muy posiblemente se asignan algunos valores a sus propiedades), es necesaria asociarla al ObjectList... Podríamos hacer algo como:

Código Delphi [-]
procedure TMovimiento.AsociarLineaDeMovimiento(Linea: TLineaDeMovimiento);
begin
  FLineasMovimiento.Add(Linea);
  // No recuerdo bien que parámetros se necesitan...
end;

Y asi podemos continuar viendo que debe hacer cada clase y/o conocer cada clase.

Ahora pensemos... ¿Sería correcto que todas la clases entiendan de SQL y sepan conectarse a la base de datos? ¿Que tienen que ver un Movimiento, un Proveedor, una LineaDeMovimiento con el acceso a base de datos? Poco y nada. Ahora tu me dirás: ¿Pero que no es que cada clase debe hacer lo que sabe y cuenta con la información para ello? ¿Pero si cada una cuenta con la información necesaria porqué no hacer que ellas sean quienes accedan a la base de datos?

La respuesta es que la verdad está a medias. Es correcto el hecho de que tanto Proveedor, como Movimientos, etc... tienen la información necesaria. Pero ¿es necesario que todas sepan y entiendan de SQL? La respuesta es NO.
Lo correcto sería tener otra clase que sepa de SQL, entienda sobre base de datos.

Viendo que me aportaste mayor información acerca de tu dominio. Yo ya optaría por algo más modular. Me hablas de Ticket y su respectivo detalle.
Ya tienes 5 clases que aprenden SQL... contra una que entiende.

Tu viniste haciendo una asignación de responsabilidades a la inversa. Hiciste el trabajo sucio en la parte alta de la rama del diagrama y debería ir en la parte baja.

Lo más correcto sería que Proveedor, y demás se comuniquen con esta clase extraña que entiende de base de datos y nada más que de base de datos y le pasan los datos lo que se desea grabar, modificar, etc.

Por ejemplo tal vez algo como esto:

Código Delphi [-]
procedure TMovimiento.Registrar(Movimiento: TMovimiento);
begin
  AccesoDB.Grabar(Self);
end;

AccesoDB, podría leer desde las propiedades del Movimiento y en base a lo que lee arma un SQL y lo manda a ejecutar.

Lo más correcto es que no haya una única clase que se encargue del trabajo sucio. Es de esperar que sean varios objetos quienes colaboran en dicha tarea.

Yo ya te he comentado que si te impongo un modelo y mi punto de vista sería perjudicial para ti. Haz el tuyo y de alli estructura las clases correctamente.
En vista a que no tienes un diseño preliminar recomiendo que antes de seguir metiendo código te documentes mejor sobre UML.
No conduzcas por la carretera de POO sino tienes un mapa que te indique si vas bien o mal.

Podríamos continuar con las explicaciones, pero es un tema que no se aprende en pocos días. si bien aqui puede que haya espacio para ir redactando cada tema o duda que te vayan surgiendo... no va alcanzar para evacuarte todas tus dudas.
Lee UML y Patrones y asimilarás la idea y la filosofía que encierra el mundo POO.

Saludos,

[NickName]

Hola Delphius Muchas gracias....

He leeido todo lo que se atraviesa en mis ojos de POO pero no es lo mismo leer que aplicar todo ya en un lenguaje en particular lo que hise y te mostre fue algo paresido a lo que vi en un curso que tome de C# por momentos sentia que estaba bien y luego sentia que no... bueno a mi me gusta delphi por eso lo elegi como lenguaje o mas bien tengo algo de tiempo haciendo cosas y siempre que desarrollo algo tenia que hacer todo de nuevo por eso elegi hacerlo ahora Orientado a objetos se que cuesta mucho se codifica mas pero todo tiene su recompensa y siento que al final me sentire bien por el trabajo realizado...
Si entiendo todo lo que me dijiste hoy prometo leer todo lo que pueda del primer libro que me recomendaste (Uml y Patrones) ya sabia que me costaria mucho pero no me arrepiento de haber elegido esta forma de desarrollo...

Lo más correcto sería que Proveedor, y demás se comuniquen con esta clase extraña que entiende de base de datos y nada más que de base de datos y le pasan los datos lo que se desea grabar, modificar, etc.

Por ejemplo tal vez algo como esto:


Código Delphi [-]procedure TMovimiento.Registrar(Movimiento: TMovimiento);
begin
AccesoDB.Grabar(Self);
end;
AccesoDB, podría leer desde las propiedades del Movimiento y en base a lo que lee arma un SQL y lo manda a ejecutar.

Esto era lo que trataba de hacer pero nunca me llego la idea de como hacerlo... No se tu pero siento que en estos casos todo lo que a uno le dicen o vee es bueno ya que como te comente no es lo mismo leer que hacer...
No tenia ni idea y me preguntaba como sabra la clase AccesoDb que Grabar si se supone que tengo Clientes, Proveedores Ticket etc etc y cada clase tiene distintos campos... y por eso aplique lo que vi en ese curso que te digo que no me convencia...

Yo ya te he comentado que si te impongo un modelo y mi punto de vista sería perjudicial para ti. Haz el tuyo y de alli estructura las clases correctamente.

Siento que me ayudaria el modelo que dices que me impondrias yo no siento que seria asi... siento que entre mas ideas tenga mejor lo hare... el libro lo leere por que nunca he hecho un diseño...
De verdad te agradezco mucho toda tu ayuda se que cuesta mucho saber lo que sabes por eso muchas gracias por aportar Toda esa Luz... bueno mejor dicho Conocimientos...

[[Delphius]]

Empezado por NickName

Hola Delphius Muchas gracias....

He leeido todo lo que se atraviesa en mis ojos de POO pero no es lo mismo leer que aplicar todo ya en un lenguaje en particular lo que hise y te mostre fue algo paresido a lo que vi en un curso que tome de C# por momentos sentia que estaba bien y luego sentia que no...

De nada, me da gusto en poder ayudar en algo...
Es cierto, no es lo mismo leer que aplicarlo. Sobre todo si lo que lees está redactado y usa de ejemplo otro lenguaje.

Personalmente opino que cuando uno se siente confuso sobre la manera en que está trabajando es una muestra de un diseño débil. Aunque también es posible que se esté buscando a un arbol dentro del bosque.
No lo tomes a mal, sino como un largo proceso de maduración.

Empezado por NickName

bueno a mi me gusta delphi por eso lo elegi como lenguaje o mas bien tengo algo de tiempo haciendo cosas y siempre que desarrollo algo tenia que hacer todo de nuevo por eso elegi hacerlo ahora Orientado a objetos se que cuesta mucho se codifica mas pero todo tiene su recompensa y siento que al final me sentire bien por el trabajo realizado...

Ummm. ¿Que se programa más siguiendo OO? Ummm yo diría que todo lo contrario. Podría ser la excepción cuando se trata de elaborar las clases que te servirán de propósito general. Pero en fin, si el sentimiento de que programas más empleando OO persiste estás en presencia de una falta de comprensión de la asignación de responsabilidades. No te critico, sino más bien es un consejo. Lo correcto sería que el esfuerzo de trabajo debería ir decajendo a medida que se sigue el diagrama del dominio o el diagrama de clase.

Empezado por NickName

Si entiendo todo lo que me dijiste hoy prometo leer todo lo que pueda del primer libro que me recomendaste (Uml y Patrones) ya sabia que me costaria mucho pero no me arrepiento de haber elegido esta forma de desarrollo...

Al comienzo cuesta, como a mi... De hecho amigo... a mi me cuesta dominar algunas cosas de la POO. No soy el gran maestro en el arte OO, pero en algo se puede... ayudar.
Lo correcto y lo primordial a aprender: Armar las relaciones entre los objetos y los Patrones GRASP: Asignación de responsabilidades. Son intuitivos (al menos yo a estas alturas los siento así). Pero patrones más avanzados como Factoría, Estrategia, Composite... no se les entiende a la primera (De hecho me estoy peleando con la Factoria).

A medida que continúes con la lectura de el libro comprenderás de lo que te he dicho. De hecho debería serte familiar lo que dije antes. Ya que el ejemplo lo he adaptado de el libro

Empezado por NickName

Esto era lo que trataba de hacer pero nunca me llego la idea de como hacerlo... No se tu pero siento que en estos casos todo lo que a uno le dicen o vee es bueno ya que como te comente no es lo mismo leer que hacer...
No tenia ni idea y me preguntaba como sabra la clase AccesoDb que Grabar si se supone que tengo Clientes, Proveedores Ticket etc etc y cada clase tiene distintos campos... y por eso aplique lo que vi en ese curso que te digo que no me convencia...

Es bueno estar atento a las alternativas, pero si recién estás incursionando en el mundo OO debes tener más firme los conceptos para comprender lo que te decimos.

Por eso te decía que es mucho más probable de que no sea una única clase la que hace el trabajo sucio. Es posible que haya una o dos más. Pero en fin, si bien puede parecerte que añadir más clases al modelo te resulta complicado notarás que las clases se volverán más relajadas, con lo que:
1. Cada clase se vuelve más estable.
2. Mantienen un bajo acoplamiento y alta cohesión. Con lo cual se vuelven fácilmente reutilizables.
3. Adosar nuevas clases hace que el modelo se amplie con poco esfuerzo.

Empezado por NickName

Siento que me ayudaria el modelo que dices que me impondrias yo no siento que seria asi... siento que entre mas ideas tenga mejor lo hare... el libro lo leere por que nunca he hecho un diseño...
De verdad te agradezco mucho toda tu ayuda se que cuesta mucho saber lo que sabes por eso muchas gracias por aportar Toda esa Luz... bueno mejor dicho Conocimientos...

Sigo pensando que imponerte el modelo es contraproducente. Sobre todo si no te haz incursionado en el mundo de UML.
Aprende UML primero y el modelo del dominio pronto te saldrá de la cabeza y notarás las cosas más frescas.

Ya he dicho que no soy el gran experto, me haces sonrojar. Te agradezco que tomes mis palabras en cuenta. Te doy mi consejo, algo que ya te he dicho antes: El modelo no es único. Eso es lo lindo de la POO, que un mismo dominio posee diversas interpretaciones y buscar la más adecuada es más de arte que de ciencia.

Saludos,

[NickName]

Ok Delphius...

Seguiere hechandole a la lectura... y en unos de estos dias haber si ya puedo con el diseño... y les comento....
Bueno por todo gracias de verdad...

[[David]]

Empezado por NickName

function TProveedores.Insertar_Proveedor: Boolean;
begin
With Operacion Do
Begin
SQL.Clear;
SQL.Add('Insert Into Proveedores(Nombre_Proveedor, Estado, Ciudad, Colonia, Calle, Codigo_Postal, Fax, Pagina_Web)' +
'Values(:Nombre_Proveedor, :Estado, :Ciudad, :Colonia, :Calle, :Codigo_Postal, :Fax, :Pagina_Web)');
ParamByName('Nombre_Proveedor').AsString:=Nombre_Proveedor;
ParamByName('Estado').AsString:=Estado;
ParamByName('Ciudad').AsString:=Ciudad;
ParamByName('Colonia').AsString:=Colonia;

Hola, tengo una duda sobre este código, tienes parametros, para el proveedor,estado,ciudad,etc... a estos parametros le asignas el valor de la propiedad Estado,Ciudad,etc... Pero donde estableces el valor para el Estado, ciudad, etc...

[NickName]

Hola...

Empezado por David
Hola, tengo una duda sobre este código, tienes parametros, para el proveedor,estado,ciudad,etc... a estos parametros le asignas el valor de la propiedad Estado,Ciudad,etc... Pero donde estableces el valor para el Estado, ciudad, etc...

El valor de las propiedades los establesco desde la capa de presentación., de una ventana donde capturo esos datos. Esto segun yo por lo que habia leeido que la Capa de presentación no se mezclaria con la capa de la logica de mi aplicación y pues fue lo que se me ocurrio...

Por ejemplo para asignar el nombre del proveedor hago algo parecido a:

Código Delphi [-]
Proveedor.Nombre:=Edit1.Text;

Despues solo ejecuto el metodo que desee atravez de algun boton

Código Delphi [-]
If Proveedores.Insertar_Proveedor Then
 Begin
 // Actualizo la lista de proveedores q la tengo en una Grilla
 End;

Espero y me alla explicado y te sirva un poco...