Enterprise Library: Data Access Application Block

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.Database dbTampico =
DAB.DatabaseFactory.CreateDatabase(“cnTampico”);

5 thoughts on “Enterprise Library: Data Access Application Block”

  1. 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.

  2. 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

  3. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *