Hola,
La información asociada a la configuración de Enterprise Library es muy amplia y puede hacer que nuestro web.config o app.config adquieran un tamaño demasiado grande para que sea gestionable.
Con tal de solucionarlo, existe la posibilidad de separar cada una de las configuraciones de los diferentes “blocks” en ficheros separados.
A continuación un artículo que describe cómo aplicarlo.
https://intelligence4.wordpress.com/2011/01/14/separating-out-enterprise-library-v5-files/
Un saludo.
Miguel.
Category: Enterprise Library
Enterprise Library, descripción general
Hola,
Iba a comenzar un especial sobre Enterprise Library, pero al realizar un análisis de mercado al respecto me he encontrado una web que explica cada uno de los Application Blocks estupendamente, así que me voy a limitar a incorporar el link al grupo de artículos 😉
Viva la reutilización de componentes.
https://rmottap.blogspot.com.es/2009/07/enterprise-library.html
Un saludo.
Miguel.
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.DatabaseFactory.CreateDatabase(“cnTampico”);