Y es que a la hora de acceder a una base de datos tenemos tantas opciones que muchas veces lo complicado es intentar decidir cuál de todas resulta la mejor para nuestro proyecto y/o organización.
Trabajando con .NET los dos motores de base de datos más empleados son SQL Server y Oracle, y para acceder a ellos desde una de nuestras aplicaciones podemos pasar desde utilizar los drivers propios de Microsoft para acceder a ambos gestores, con clases propuestas por el propio framework, podemos acceder a oracle a traves de los Oracle Data Access Components (ODAC) para .NET, podemos usar Datasets Tipados con sus correspondientes TableAdapter para aliviar algo el tiempo de construcción… utilizar patrones de acceso a datos como DAO+DTO… y un largo etcétera que puede pasar por soluciones caseras más o menos elaboradas, aplicaciones de otros patrones de acceso a datos como puede ser Active Record o herramientas de acceso a datos orientadas entidades como el nuevo Microsoft Entity Framework y la versión de Hibernate para .NET, NHibernate. Para más diversión, incluso pueden emplearse combinaciones de alguna de las herramientas descritas en el párrafo, intentando ajustar el esfuerzo de construcción a nuestro proyecto y, lo más complicado de todo, a nuestra planificación 🙂
Pues ante toda esta lista interminable de herramientas, cada una con sus pros y sus contras, añado y expongo a continuación las ventajas aportadas por otra más, las Enterprise Library con su funcionalidad de acceso a datos: Data Access Application Block.
¿Qué nos aporta el Data Access Application Block?
Pues una de las principales ventajas que aporta el framework es que permite con la misma codificación atacar a diferentes gestores de bases de datos, es decir, tras preparar el acceso a datos de nuestra aplicación con enterprise library, podríamos ser capaces sin cambiar ni una línea de código (no os toméis esto al pie de la letra, que seguro que algo habrá que cambiar aunque sea mínimo), de pasar de atacar a un SQL Server a un Oracle. Esta puede ser una gran ventaja si estáis preparando un producto al que dependiendo del cliente al que se lo vendáis tengáis que garantizar el soporte de ambos gestores, porque por ejemplo alguno de vuestros clientes esté casado con Oracle y otro con SQL Server. Con un sólo desarrollo de vuestra capa de acceso a datos cubriréis toda la casuística (menos los procedimientos almacenados, claro, que os va a tocar picarlos dos veces :)).
Otras ventajas a tener en cuenta son la facilidad de configuración. Una vez instaladas las enterprise library disponemos de una pequeña aplicación que apuntándola al Web.Config o App.Config de nuestro aplicativo permite editar las propiedades de conexión de manera visual. Pudiendo configurar el proveedor de la conexión, tipos de autenticación y más parámetros propios de una conexión a datos de forma muy cómoda y sencilla.
Una vez configurada la conexión, con una línea como la siguiente conectamos con el gestor, independientemente de cuál sea (DataBase y DataBaseFactory son clases del Data Access Application Block).
Database nuestraDB = DatabaseFactory.CreateDatabase(“nombreConnectionString”);
Para hacer una consulta que retorne un conjunto de registros a través de un procedimiento almacenado:
DataReader ejemploDR = nuestraDB.ExecuteReader(CommandType.StoredProcedure, “spu_get_allitems”);
Y para recorrer el datareader, pues como siempre, utilizando el método Read y luego en el registro sobre el que trabajamos obteniendo el dato a través del identificador de la columna.
Como véis es rápido y sencillo (no tanto para los que os toque trabajar contra Oracle, ya que os vais a necesitar conocer algíºn truquillo extra), y os ayuda a mantener una total independencia con el gestor de base de datos.
Bajo mi humilde opinión, Data Access Application Block podría ser un buen candidato a herramienta de acceso a datos corporativo en cuanto al desarrollo de soluciones .NET.
Saludos.
Miguel.
DAB.DatabaseFactory.CreateDatabase(“cnTampico”);
Interesante comentario acerca de las facilidades que tiene usar enterprise library, estoy en estudio de este tema y no se si seria una molestia que me puedas pasar un ejemplo, tengo uno pero quiero ver si puedo bajar las lineas de código, gracias.
Esta muy interesante tu aporte.
Porfa si tienes mas info sobre Enterprise Library Data Acces Application Block
podrás enviarla a mi correo.
lizlatina_850@hotmail.com
Gracias!!
Como seria el ejemplo si se tuviera un procedimiento almacenado que devuelve varias filas
Hola, buen aporte, me podrias dar una mano? este es mi codigo y quiero pasar un SqlParammeter con tres valores…
serchValu[0] = new SqlParameter(“@nombre”, ddlSucursal.SelectedValue);
serchValu[1] = new SqlParameter(“@fechaInicio”, ddlFechaInicio.SelectedValue.ToString());
serchValu[2] = new SqlParameter(“@fechaFinal”, ddlFechaFinal.SelectedValue.ToString());
Database db = DatabaseFactory.CreateDatabase(“BaseSantaMariaConnectionString”);
// el nombre es string, fechaInicio y fechaFinal son DateTime
//y quiero llenar mi DataSet asi
miDataSet = db.ExecuteDataSet(“spRecuperarDatosFechaInicioFin”, serchValu);
ReportDataSource datasource = new ReportDataSource(“DataSetVentas”, miDataSet.Tables[0]);
//el store procedure es el siguiente
ALTER PROCEDURE [dbo].[spRecuperarDatosFechaInicioFin]
@nombre varchar (30),
@fechaInicio varchar (30),
@fechaFinal varchar (30)
AS
BEGIN
SELECT Articulo.nombre, det.precioUnidad, det.cantidadSolicitada, enc.total
FROM RemitoVenta AS enc, DetalleVenta As det, Articulo, Sucursal
WHERE
Sucursal.idSucursal=enc.idSucursal AND
Articulo.idArticulo=det.idArticulo AND
enc.idEncRemitoVenta=det.idEncRemitoVenta AND
Sucursal.nombre=@nombre AND
(enc.fecha BETWEEN @fechaInicio AND @fechaFinal)
;
END
ERROR: Error al convertir el valor del parámetro de SqlParameter a String.
Gracias
Hola,
Disculpad, pero me es muy complicado por cuestión de tiempo responder a preguntas concretas de revisión de código o crear ejemplos específicos bajo demanda. Al crear los artículos si de base cuento con tiempo ya incluyo un ejemplo de código; en su defecto incluyo pseudo-código; en su defecto cuento la historia por encima esperando que al menos os quedéis con la idea y a partir de ahí podáis investigar por vuestra cuenta.
Intentando hacer una excepción, Pedro:
Comprueba el tipo de dato con el que has definido las fechas en tu base de datos, me extraña que sea un varchar; adáptalo a un tipo fecha a nivel de tabla y en tu procedimiento almacenado. Adicionalmente al utilizar SqlParameter juraría que tiene una sobrecarga para indicar el tipo de dato del parámetro y hay uno para fecha, indícaselo, y pasa la fecha sin hacer el tostring. A ver si así mejora la cosa.
Un saludo.