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