La importancia de la independencia entre capas a veces deja al margen la capa almacenadora de datos.
Con "Entity Framework" podemos llegar a obtener esta independencia, dotando a la capa DAL (Capa de acceso a los datos) de herramientas para obtener un Contexto de base de datos independiente.
Cada vez es más importante tener una arquitectura estable basada en capas, y que facilite tanto el desarrollo como el mantenimiento de las aplicaciones, además de potenciar la reutilización de los componentes ya implementados. De hecho, ya no son raras las ofertas de trabajo en las que se pide un arquitecto de software que ayude a conseguir estos objetivos.
Pero cuando hablamos de la independencia entre capas, muchas veces pasamos por alto la capa servidora de datos. No estamos hablando de la capa DAL sino del servidor de base de datos propiamente dicho. Y es que, muchas veces, los productos están ligados a un único servidor de base de datos, obligando al cliente a tener una instancia del repositorio elegido (Oracle, SQLServer..etc.)
Para nuestro ejemplo, intentaremos dar una solución que mantenga el objetivo de tener un solo archivo .Edmx, el cual pueda atacar a una base de datos Oracle y otra SQLServer. Para ello buscaremos proveedores de Oracle que soporten EF. El propio de Oracle nos servirá para este propósito, aunque no es desdeñable la opción de usar el de Devart, el cual hay que decir que funciona muy bien.
A partir de ahí crearemos un Edmx con la conexión a SQLServer (base de datos que creemos que será la más utilizada en nuestras instalaciones), y con el wizard iremos mapeando la base de datos según nuestras necesidades.
Como se puede ver, hemos creado un programa que prueba esta "dll" (es simplemente por dejarlo más bonito), pero para pruebas recomendamos encarecidamente los proyectos de test.
Una vez generado el Archivo FerDB, hay que comentar que al compilar, genera en la carpeta obj/debug/edmxResourcesToEmbed, una serie de archivos XML, con el mapeo y configuración del acceso a la base de datos. Estos archivos tienen extensión:
- .csdl: Con la enumeración de las entidades
- .msl: Con el mapeo de la base de datos
- .ssdl:Con la definición de acceso y las entidades generadas
A continuación cambiaremos el proveedor de SQL al provider que estamos utilizando en ese momento.
<Schema Namespace="FERDB.Store" Alias="Self" Provider="System.Data.OracleClient" ProviderManifestToken="2008" xmlns:store="http://schemas.microsoft.com/ado/2007/12/edm/EntityStoreSchemaGenerator" xmlns="http://schemas.microsoft.com/ado/2009/02/edm/ssdl">
<EntityContainer Name="FERDBStoreContainer">
<EntitySet Name="PERSONA" EntityType="FERDB.Store.PERSONA" store:Type="Tables" Schema="dbo" />
Por último, nos falta pasarle una cadena de conexión diferente en cada caso (parecido a lo que se hacía en ADO.Net cuando se utilizaba un "oledbconnection", para conectar a varios servidores de base de datos).
Public Class clsAcceso
Public Enum eATM_BaseDatos
Oracle
SQL
End Enum
Public Function GetDataModel(ByVal proveedor As eATM_BaseDatos, ByVal instancia As String, ByVal base As String) As EF_ATMContaEntidades
Dim ctx As EF_ATMContaEntidades
Select Case proveedor
Case eATM_BaseDatos.Oracle
ctx = New EF_ATMContaEntidades(String.Format(
"provider=System.Data.OracleClient;metadata=D:
FERATM_DAL_4_0ATMEntity_4objDebugedmxResourcesToEmbedFerBD_Oracle.ssdl|res:
//*/FerBD.csdl|res://*/FerBD.msl;Provider Connection String='
User Id=fer;Password=fer;Server={0};Direct=True;Sid={1};'",
instancia, base))
Case eATM_BaseDatos.SQL
ctx = New EF_ATMContaEntidades(String.Format("provider=System.Data.SqlClient;metadata=res:
//*/FerBD.csdl|res://*/FerBD.ssdl|res:
//*/FerBD.msl;Provider Connection String='server={0};Initial Catalog={1}; integrated security=true;
User Id=fer;Password=fer;database={1};'", instancia, base))
End Select
If ctx IsNot Nothing Then
Return ctx
Else
Throw New Exception("Error al generarl el contexto")
End If
End Function
End Class
En este caso hemos creado la cadena de conexión independiente, como si tuviéramos dos edmx, pero al tener solo uno, además del proveedor debemos decir cual es el fichero de recursos de Oracle y cual el de SQL Server.
Con esto ya tenemos nuestra DLL de multiacceso, y lista para ser probada.
CONCLUSIÓN
Cada vez es más importante la creación de arquitecturas robustas, donde cada capa sea independiente, y además poder aprovecharnos de todas las ventajas que los ORMs pueden darnos. Con Entity Framework, podemos obtener los beneficios de ambas, a un coste no excesivo, ya que todo lo que hay que hacer es dotar de decisión a la capa DAL y configurar los accesos a las bases de datos que vayamos a utilizar.Fernando Gómez Muñoz
Desarrollador web, especialista en ASP.Net y desarrollos con arquitectura SOA.