Capa DAL - Entity Framework.

Como comentaba en la entrada previa, vamos a ver el primer proyecto que compone nuestra solución.
Es la capa DAL (Data Access Layer) que nos va a ayudar con la persistencia de datos.

Para ello usamos Entity Framework, que de manera resumida, es un conjunto de tecnologías ADO .NET que genera un modelo de datos ligado directamente con la base de datos. Es decir, que con EF manejamos objetos y nos abstraemos de las sentencias SQL para leer o actualizar la base de datos.
Por ejemplo, en el proyecto que nos ocupa, tenemos una tabla Conceptos para indicar el concepto de un movimiento (si es un gasto de Gasoil, un ingreso por nómina, ....)
Bien pues con EF, tendremos un objeto Concepto, con los mismos atributos (propiedades) que la tabla subyacente en SQL Server (columnas), pero cuando queramos modificar un concepto haremos algo como esto (no es código literal)

  concepto.Descripcion = "Descripcion 1"
  contexto.Save();

Y EF se encargará de generar la sentencia UPDATE correspondiente.

Alguna vez me han comentado que en algunas circunstancias, EF no tiene un buen rendimiento. Mi experiencia, con varias aplicaciones de uso intensivo de base de datos, es bastante buena. Nunca he tenido problemas de rendimiento causados por EF; siempre han sido vistas o procedimientos mal diseñados/programados. Ahora bien, es cierto que cumplo una norma. Quien mejor maneja los datos, es la base de datos y nunca hago joins que tenga que gestionar EF.
Si observamos el modelo de datos que publiqué, vemos que hay una vista (vwMovimientos) que se encarga de unir las tablas que necesito para mostrar la información de movimientos. (Pongo el código para verlo más fácilmente)

Alter View vwMovimientos as 
Select Movimientos.Id, UserName, FechaMovimiento, IdConcepto, Importe,Saldo, Conceptos.Descripcion as Concepto
From Movimientos
Inner Join Conceptos ON Conceptos.Id = Movimientos.IdConcepto
order by FechaMovimiento Desc

Bueno, se ve que es un join sencillo; pero me preocupa perder el control. Si mañana necesito depurar esta vista, desde SQL Server lo puedo hacer; si tengo que crear un índice, desde SQL Server lo puedo hacer. Evidentemente lo mismo puedo hacer para que funcione correctamente desde EF, pero tengo la sensación de perder un poco el control.
Un objeto de mi modelo puede estar mapeado, a la hora de la lectura, con varios objetos de EF.



Creando el modelo en EF

Para crear los objetos de EF, nos posicionamos sobre nuestro proyecto (en este caso EliteDAL) y con el botón derecho del ratón, seleccionamos añadir nuevo elemento. En el menú izquierdo, seleccionamos Data y en el centro pulsamos sobre ADO .NET Entity Data Model y ponemos un nombre a nuestro modelo

Después seleccionamos Code First from database, para generar nuestro conjunto de tipos POCO.

Seleccionamos una conexión y finalmente escogemos las entidades de la base de datos que vamos a pasar a nuestro modelo de EF

Al darle finalizar, veremos que automáticamente tenemos nuestros objetos POCO, listos para ser usados.


En la próxima entrada seguiremos con nuestro proyecto DAL, añadiendo Unit of Work.