4 replies to this topic

[cram]

El asunto es este y si me equivoco, pido por favor a aquellos reconocidos maestros o cualquier otro que se sienta cómodo y seguro para corregirme que lo haga.

 

Un consejo simple.

 

Siempre que creo un Datamodule suelo hacerlo definiendo ahí mismo las transacciones y la base de datos. Además creo en forma visual las consultas, datasets, tablas, procedimientos, etc.

Para cerrar más cualquier idea hablo del uso de Interbase express.

 

Esto me permite controlar los eventos y lo que comúnmente llaman lógica de negocio.

También es posible encapsular todo este mecanismo, haciéndolo a la vez, más fácil de hallar errores.

 

Al utilizar controles en un TForm será necesario crear un data source (TDataSource) que haga de interfaz entre el control visual y el componente que a su vez hace de interfaz con la base de datos que puede ser una tabl, una consulta, etc.

 

En fin lo que quiero comentar es que solía, no se si por comodidad o por "inercia" acceder a los campos de los datasets del datamodule de la siguiente manera:

php

dsUnDataSource.Dataset.FieldByName('NOMBRE_CAMPO').AsTiipo;

Por lo que arrastrado una vez más por esta "inercia" solía crear un DataSource por cada dataset que utilizaría en el form. Pero más tarde hallé que esto es en sí un error por ser algo innecesario e indirecto.

Lo que hago actualmente es:

php

dmUnDataModule.qryUnaConsula.FieldByName('NOMBRE_CAMPO').AsTipo;

Al parecer es lo mismo, pero en realidad es algo más directo y además permite acceder a muchas características propias del tipo de objeto que fuere, por ejemplo un procedimiento, un dataset, una consulta, una tabla, tendrán eventos y propiedades que no pueden ser accedidas desde el objeto dataset que está atado al datasource. Esto me trajo muchas complicaciones en cuanto a la claridad del código, ya que a veces aparecía la primera versión y cuando era necesario, la segunda, con lo que me consumía más tiempo.

 

En el ejemplo escribí FieldByName, puede ser FieldValue, etc

 

Otra de las ventajas de no acceder indirectamente a los datasets es que se evita la creación de objetos innecesarios.

 

Es posible acceder a los datasets desde el mismo objeto visual, pero ese es otro tema.

También sé que hay personas que no utilizan datamodules, ni crean estos objetos de forma visual, pero eso ya va en gusto y cabe la aclaración que de la segunda manera es posible hallar errores más fácilmente.

 

Saludos

 

[Wilson]

Hola Cram, si se puede acceder a las características específicas del objeto que desees haciendo un Cast.

 

Por ejemplo el dataset en este caso es un TClientDatset:

delphi

if assigned(DataSource1.DataSet) then
begin
(TClientDataset(DataSource1.DataSet)).CommandText := '' ;
(TClientDataSet(DataSource1.DataSet)).OnReconcileError := //hacer algo ;
 
//O de esta otra forma
 
(DataSource1.DataSet as TClientDataset).CommandText := '';
//...
end;

Incluso sirve para hacer más general el procedimiento (que te sirva para más cosas)  y que trabaje en función del tipo de dataset, por ejemplo:

delphi

if assigned(DataSource1.DataSet) then
begin  
if DataSource1.DataSet.ClassType = TClientDataSet then
   (TClientDataSet(DataSource1.DataSet)).CommandText := '';
 
 if DataSource1.DataSet.ClassType = //otro tipo then
    //Hacer otra cosa;
end;

Incluso en muchos casos (en mis desarrollos)  el DataSource cambia de Dataset dinámicamente.

 

Es tan flexible que yo utilizo un form base de la cual heredo todos los form en los que voy a insertar o editar los registros en toda la aplicación y, los procedimientos de guardado o cancelado (virtuales) los encapsulo justo con el DataSource, cada que me ha tocado por algún motivo utilizar un dataset diferente, basta con agregar una línea de código en el form base para decirle que hacer con el nuevo dataset.

 

Saludos.

[cram]

Hola Cram, si se puede acceder a las características específicas del objeto que desees haciendo un Cast.

 

Por ejemplo el dataset en este caso es un TClientDatset:

delphi

if assigned(DataSource1.DataSet) then
begin
(TClientDataset(DataSource1.DataSet)).CommandText := '' ;
(TClientDataSet(DataSource1.DataSet)).OnReconcileError := //hacer algo ;
 
//O de esta otra forma
 
(DataSource1.DataSet as TClientDataset).CommandText := '';
//...
end;

Incluso sirve para hacer más general el procedimiento (que te sirva para más cosas)  y que trabaje en función del tipo de dataset, por ejemplo:

delphi

if assigned(DataSource1.DataSet) then
begin  
if DataSource1.DataSet.ClassType = TClientDataSet then
   (TClientDataSet(DataSource1.DataSet)).CommandText := '';
 
 if DataSource1.DataSet.ClassType = //otro tipo then
    //Hacer otra cosa;
end;

Incluso en muchos casos (en mis desarrollos)  el DataSource cambia de Dataset dinámicamente.

 

Es tan flexible que yo utilizo un form base de la cual heredo todos los form en los que voy a insertar o editar los registros en toda la aplicación y, los procedimientos de guardado o cancelado (virtuales) los encapsulo justo con el DataSource, cada que me ha tocado por algún motivo utilizar un dataset diferente, basta con agregar una línea de código en el form base para decirle que hacer con el nuevo dataset.

 

Saludos.

 

Que interesante la idea. Aún así siempre busco la facilidad para leer el código, Aunque, me imagino que de la manera que implementas eso, el código se reduce mucho. Me refiero que al estar concentrado en un único método el código es, en definitiva, más reducido.

Y por supuesto, que se puede hacer siempre un casting y que la flexibilidad es impresionante.

También me gusta generalizar los métodos, pero no llegué a eso

 

Saludos

[Wilson]

Que interesante la idea. Aún así siempre busco la facilidad para leer el código, Aunque, me imagino que de la manera que implementas eso, el código se reduce mucho. Me refiero que al estar concentrado en un único método el código es, en definitiva, más reducido.

Y por supuesto, que se puede hacer siempre un casting y que la flexibilidad es impresionante.

También me gusta generalizar los métodos, pero no llegué a eso

 

Saludos

 

 

El objetivo principal de este tipo de programación es la reutilización de código, yo utilizo (y reutilizo) las mismas clases para todas las aplicaciones que tienen que ver con bases de datos, si algo nuevo aparece lo agrego a las clases base y listo (que dicho se a de paso, quedan enriquecidas para la próxima aplicación), si hay algo complicado o especial por hacer en algún form específico, simplemente redefino el método en la clase hija.

 

En este contexto el TDataSource principal de las clases base juega un papel protagónico y, se ahorra mucho, muchísimo código y trabajo. Tengo aplicaciones de este tipo con 40 o 50 forms sin una sola línea de código, todo reside en las clases base de edición, navegación y búsquedas, por supuesto todo depende del tipo de aplicación, habrá algunas en donde toca agregar algún código en las clases hijas.

 

Un cordial saludo.

[FerCastro]

Winson, muy interesante tema. tendrás un ejemplo de cómo lo implementas? hablo de la encapsulación, pues me resulta muy interesante a la hora de ahorrar código (ley del mínimo esfuerzo)

 

Saludos y gracias