Componente de acceso a datos,por instanciacion o con metodos estaticos?

Francamente yo creo que es cuestión de preferencias personales. Como lo
mencionas, la diferencia está en que típicamente un componente de acceso a
datos no conserva estado y por lo tanto se aleja de la definición formal de
una clase que es un 'elemento programático que agrupa estado (miembros de
datos) y comportamiento (métodos)'.

A mi parecer, ese es el punto que debes evaluar bien: si en verad tu
componente no necesita guardar estado. Tal vez después de un análisis mas
detenido, te des cuenta de que tu componente neceista datos modificables,
como, no sé, la cadena de conexión, el id del usuario o el timeout de los
comandos. Usando métodos de instancia podrías lograr que cada vez que
alguien va a invocar el componente ponga sus propios valores. Si decides
tener estos datos como miembros estáticos debes ser mucho mas cuidadosa de
los asuntos de sincronización cuando tu componente es invocado desde
diferentes threads.

Si no es asi, usar métodos estáticos te da un poco mejor desempeño por que
te ahorras la el tiempo de construcción y de destrucción de los objetos.

En otras palabras, el usar métodos estáticos es un enfoque poco orientado a
objetos y es mas parecido a una programación estructurada en donde la clase
no es mas que un 'prefijo' de una serie de métodos 'globales'. El usar
métodos de instancia te facilita la construcción de aplicaciones que
aproveches las ventajas de la POO (polimorfismo, etc..). Por ejemplo, en
escenarios de componentes de acceso a datos 'genéricos', (en donde pudieras
querer cambiar la base de datos en tiempo de configuración, y que el DAL
automaticamente usara un SqlConnection o un OracleConnection dependiendo del
proveedor configurado), es mas fácil usar el patrón de diseño ClassFactory
para obtener instancias de diferntes clases de acceso a datos que soporten
una misma interfaz o estén derivadas de una clase base, que usar distintas
clases estáticas. Un ejemplo muy simplificado es:

// definición de un componente de acceso a datos genérico
interface IGenericDal
{
DataSet ExecuteDataSet(string statement);
//
}
// fabrica de componentes de acceso a datos
public class DalFactory
{
public static IGenericDal GetDal()
{
// decidir que base de datos usar
if(config.Databse == "sqlserver") return new SqlDal();
if(config.Databse == "oracle") return new OracleDal();
}
}
// una implementación, usa métodos de instancia
public class SqlServerDal : IGenericDal
{
public DataSet ExecuteDataSet(string statement)
{
// .. usar SqlCommand, etc..
}
// ...
}

// otra implementación, usa métodos de instancia
public class OracleServerDal : IGenericDal
{
public DataSet ExecuteDataSet(string statement)
{
// ... usar OracleCommand, etc...
}
// ...
}

Un cliente usaría:

IGenericDal dal = DalFactory.GetDal();
DataSet ds = dal.ExecuteDataSet("select ... ");


Sin embargo estos escenarios no son tan frecuentes y a final de cuentas
puedes de todos modos encapsular este uso de ClassFactory's dentro de una
clase que provea puros métodos estáticos.

Yo soy partidario de la opción de usar métodos estáticos y la mayoría de las
implementaciones con que he trabajado usan ese patrón de diseño. Incluido el
Data Access Application Block de Microsoft.

Sergio

"Carla" wrote in message
news:031e01c3c330$4252e040$

Hola a todos
Tengo que hacer un componente de acceso a datos.He visto
varios ejemplos en la red ,varios en las paginas de
Microsoft.La cosa es que todos se hacen sobre clases que
despues se instanciaran en la aplicacion, no con metodos
estaticos, cosa que me parece mas logico puesto que este
componente no almacena ningun tipo de estado.Pero tambien
pienso que si se hace asi, por algo sera.
Que opinais?
Que beneficios e inconvenientes tendria hacerlo estatico,
con metodos como "static DataSet ExecuteProcedure()"?

Gracias y un saludo

Gracias,la verdad es que te agradezco mucho toda la
explicacion.La cosa es que entre que puse el msj han
modificado las especificaciones y ahora se puede acceder
a la clase desde distintos sitios a la vez, con lo cual
si la hago estatica me podria traer problemas
de "concurrencia" por si, por ejemplo, tengo almacenados
parametros en un comando y este es llamado por otro
metodo en ese momento.Con lo cual creo que usare
instanciacion.Pero como digo, tu explicacion me ha
despejado dudas.

Muchas gracias y un saludo

Francamente yo creo que es cuestión de preferencias

personales. Como lo

mencionas, la diferencia está en que típicamente un

componente de acceso a

datos no conserva estado y por lo tanto se aleja de la

definición formal de

una clase que es un 'elemento programático que agrupa

estado (miembros de

datos) y comportamiento (métodos)'.

A mi parecer, ese es el punto que debes evaluar bien: si

en verad tu

componente no necesita guardar estado. Tal vez después

de un análisis mas

detenido, te des cuenta de que tu componente neceista

datos modificables,

como, no sé, la cadena de conexión, el id del usuario o

el timeout de los

comandos. Usando métodos de instancia podrías lograr que

cada vez que

alguien va a invocar el componente ponga sus propios

valores. Si decides

tener estos datos como miembros estáticos debes ser

mucho mas cuidadosa de

los asuntos de sincronización cuando tu componente es

invocado desde

diferentes threads.

Si no es asi, usar métodos estáticos te da un poco mejor

desempeño por que

te ahorras la el tiempo de construcción y de destrucción

de los objetos.

En otras palabras, el usar métodos estáticos es un

enfoque poco orientado a

objetos y es mas parecido a una programación

estructurada en donde la clase

no es mas que un 'prefijo' de una serie de

métodos 'globales'. El usar

métodos de instancia te facilita la construcción de

aplicaciones que

aproveches las ventajas de la POO (polimorfismo, etc..).

Por ejemplo, en

escenarios de componentes de acceso a datos 'genéricos',

(en donde pudieras

querer cambiar la base de datos en tiempo de

configuración, y que el DAL

automaticamente usara un SqlConnection o un

OracleConnection dependiendo del

proveedor configurado), es mas fácil usar el patrón de

diseño ClassFactory

para obtener instancias de diferntes clases de acceso a

datos que soporten

una misma interfaz o estén derivadas de una clase base,

que usar distintas

clases estáticas. Un ejemplo muy simplificado es:

// definición de un componente de acceso a datos genérico
interface IGenericDal
{
DataSet ExecuteDataSet(string statement);
//
}
// fabrica de componentes de acceso a datos
public class DalFactory
{
public static IGenericDal GetDal()
{
// decidir que base de datos usar
if(config.Databse == "sqlserver") return new

SqlDal();

if(config.Databse == "oracle") return new

OracleDal();

}
}
// una implementación, usa métodos de instancia
public class SqlServerDal : IGenericDal
{
public DataSet ExecuteDataSet(string statement)
{
// .. usar SqlCommand, etc..
}
// ...
}

// otra implementación, usa métodos de instancia
public class OracleServerDal : IGenericDal
{
public DataSet ExecuteDataSet(string statement)
{
// ... usar OracleCommand, etc...
}
// ...
}

Un cliente usaría:

IGenericDal dal = DalFactory.GetDal();
DataSet ds = dal.ExecuteDataSet("select ... ");


Sin embargo estos escenarios no son tan frecuentes y a

final de cuentas

puedes de todos modos encapsular este uso de

ClassFactory's dentro de una

clase que provea puros métodos estáticos.

Yo soy partidario de la opción de usar métodos estáticos

y la mayoría de las

implementaciones con que he trabajado usan ese patrón de

diseño. Incluido el

Data Access Application Block de Microsoft.

Sergio

"Carla" wrote in

message

news:031e01c3c330$4252e040$

Hola a todos
Tengo que hacer un componente de acceso a datos.He

visto

varios ejemplos en la red ,varios en las paginas de
Microsoft.La cosa es que todos se hacen sobre clases

que

despues se instanciaran en la aplicacion, no con

metodos

estaticos, cosa que me parece mas logico puesto que

este

componente no almacena ningun tipo de estado.Pero

tambien

pienso que si se hace asi, por algo sera.
Que opinais?
Que beneficios e inconvenientes tendria hacerlo

estatico,

con metodos como "static DataSet ExecuteProcedure()"?

Gracias y un saludo

.

Hola Sergio , Carla.

Sergio es muy explicativo tu correo, es muy bueno.

Quisiera charlar sobre ciertos puntos de tu correo.

Primer punto - DAL - Data Access Application Block de
Microsoft y demas patrones y/o Framework

Personalmente creo que estas "pseudo aplicaciones" SON
DOCUMENTOS
sobre como aplicar a modelos que pueden crecer en el
tiempo
sin importar una entre tantas cosas, el motor de base de
datos. Son consejos de OTRO
sobre como ve este tema. Mirarlo desde este punto, como un
consejo no esta mal.
Si creo, que es un error usarlo como tu propia "cascara"
(Framwork) a tu implementacion.
Ya que no es una "cascara", no es un framework, son
adaptadores (wrappers) que en el mejor de los casos
lo realizo ortra persona que el mismo lo documento. Este
adaptador para el mismo que lo idea seguro que es el
mejor, PERO
PARA EL, no para OTRO. El problema de los patterns,
wrpappers, es que ultimamente estan de modas. Y como la
moda la
gente lo usa por que si y sin saber o mejor dicho una
investigacion sobre el significado cada patterns (que no
es mas ni menos
que una solucion GENERALIZADa a problemas recurrentes
generalizados ). Usar un patterns o wrappers de memoria o
de libro
o de MSDN es un mono con revolver.
Con todo esto quiero decir que hay que tomar solo la idea
IDEA de este modelo; como ejemplo el DAL. Lo mas sano
es hacer. "amasar", redefinir, nuestro propio "maquina"
(framework) que sea adaptado a nuestro problema de
negocios y no al
de otro. EL problema de este punto es que hay que tener
claro ciertos puntos y es un tiempo de estudio que
lleva.Hay que madurar las ideas y
no usar las de otro.

Segundo Dos - Metodos de instancias y Metodos de Clase

Una aclaracion antes que nada, los metodos de clase
en .net los llaman metodos static.

Sergio, decis lo siguiente:

En otras palabras, el usar métodos estáticos es un

enfoque poco orientado a

objetos y es mas parecido a una programación

estructurada en donde la clase

no es mas que un 'prefijo' de una serie de

métodos 'globales'. El usar

métodos de instancia te facilita la construcción de

aplicaciones que

aproveches las ventajas de la POO (polimorfismo, etc..).

Por que decis que un metodo estatico no tiene que ver con
la PO ?
Todo lo contratrio, es una herramienta mas , entre tantas
otras de la PO.

A ver.
los métodos de instancia y los métodos de clase pueden
referirse a las atributos de clase,
pero sólo los métodos de instancia pueden referirse a las
variables de instancia. El comportamiento
de una instancias que por teoria podria saber de si misma
los mensajes (lease protocolos de la clase), métodos,
y atributos .Los atributos puede ser de clase o de
instnacias.
Un atributo de clase apunta al estado de la clase que la
define.
Sólo existe una copia de la variable de clase en la
jerarquía local de clases, convirtiéndola en un atributo
compartido.
PERO solo se accede no se modifica. La clase que define
esta variable, y todas sus subclases, se referencian a
esta única del atributo.
NO ENTIENDO por que el problema de sincronizacion que
decis, ya que solo ACCEDE (digamos que lo consulta) al
atributo compartido.
La herramienta que se llama Jerarquia cubre este aspecto.
Segun lo que vos decis (espero entenderte bien) todos los
atributos
atributo estatico de la clase Object para abajo deberian
implelemtar un semaforo y por lo que yo se, esto no es asi.



Saludos,Marcelo.

Francamente yo creo que es cuestión de preferencias

personales. Como lo

mencionas, la diferencia está en que típicamente un

componente de acceso a

datos no conserva estado y por lo tanto se aleja de la

definición formal de

una clase que es un 'elemento programático que agrupa

estado (miembros de

datos) y comportamiento (métodos)'.

A mi parecer, ese es el punto que debes evaluar bien: si

en verad tu

componente no necesita guardar estado. Tal vez después de

un análisis mas

detenido, te des cuenta de que tu componente neceista

datos modificables,

como, no sé, la cadena de conexión, el id del usuario o

el timeout de los

comandos. Usando métodos de instancia podrías lograr que

cada vez que

alguien va a invocar el componente ponga sus propios

valores. Si decides

tener estos datos como miembros estáticos debes ser mucho

mas cuidadosa de

los asuntos de sincronización cuando tu componente es

invocado desde

diferentes threads.

Si no es asi, usar métodos estáticos te da un poco mejor

desempeño por que

te ahorras la el tiempo de construcción y de destrucción

de los objetos.

En otras palabras, el usar métodos estáticos es un

enfoque poco orientado a

objetos y es mas parecido a una programación estructurada

en donde la clase

no es mas que un 'prefijo' de una serie de

métodos 'globales'. El usar

métodos de instancia te facilita la construcción de

aplicaciones que

aproveches las ventajas de la POO (polimorfismo, etc..).

Por ejemplo, en

escenarios de componentes de acceso a datos 'genéricos',

(en donde pudieras

querer cambiar la base de datos en tiempo de

configuración, y que el DAL

automaticamente usara un SqlConnection o un

OracleConnection dependiendo del

proveedor configurado), es mas fácil usar el patrón de

diseño ClassFactory

para obtener instancias de diferntes clases de acceso a

datos que soporten

una misma interfaz o estén derivadas de una clase base,

que usar distintas

clases estáticas. Un ejemplo muy simplificado es:

// definición de un componente de acceso a datos genérico
interface IGenericDal
{
DataSet ExecuteDataSet(string statement);
//
}
// fabrica de componentes de acceso a datos
public class DalFactory
{
public static IGenericDal GetDal()
{
// decidir que base de datos usar
if(config.Databse == "sqlserver") return new

SqlDal();

if(config.Databse == "oracle") return new

OracleDal();

}
}
// una implementación, usa métodos de instancia
public class SqlServerDal : IGenericDal
{
public DataSet ExecuteDataSet(string statement)
{
// .. usar SqlCommand, etc..
}
// ...
}

// otra implementación, usa métodos de instancia
public class OracleServerDal : IGenericDal
{
public DataSet ExecuteDataSet(string statement)
{
// ... usar OracleCommand, etc...
}
// ...
}

Un cliente usaría:

IGenericDal dal = DalFactory.GetDal();
DataSet ds = dal.ExecuteDataSet("select ... ");


Sin embargo estos escenarios no son tan frecuentes y a

final de cuentas

puedes de todos modos encapsular este uso de

ClassFactory's dentro de una

clase que provea puros métodos estáticos.

Yo soy partidario de la opción de usar métodos estáticos

y la mayoría de las

implementaciones con que he trabajado usan ese patrón de

diseño. Incluido el

Data Access Application Block de Microsoft.

Sergio

"Carla" wrote in

message

news:031e01c3c330$4252e040$

Hola a todos
Tengo que hacer un componente de acceso a datos.He visto
varios ejemplos en la red ,varios en las paginas de
Microsoft.La cosa es que todos se hacen sobre clases que
despues se instanciaran en la aplicacion, no con metodos
estaticos, cosa que me parece mas logico puesto que este
componente no almacena ningun tipo de estado.Pero

tambien

pienso que si se hace asi, por algo sera.
Que opinais?
Que beneficios e inconvenientes tendria hacerlo

estatico,

con metodos como "static DataSet ExecuteProcedure()"?

Gracias y un saludo

.