Ya hemos visto la arquitectura de capas basada en el patrón MVP con dos ejemplos previamente, en el primero use LINQ to SQL para el acceso a datos, en el segundo use ADO.NET y en esta ocasión vamos a usar el Entity Framework...
Como siempre tratando de aplicar algún patrón dentro del ejemplo…
Introducción
En esta ocasión vamos a hacer un cambio sobre el modelo arquitectónico que hemos estado usando, todo con la finalidad de que avancemos en la idea de crear una API reutilizable de nuestro código.
La idea es tener una solución con dos proyectos, en el primero tendremos nuestra UI, que en este caso será Web y en el segundo la biblioteca donde tendremos nuestros servicios y el model.
O sea el UI será la parte presentadora de nuestro patrón y la biblioteca tendrá lo demás.
Creación de los proyectos
Creen dos proyectos dentro de una solución, uno debe ser ASP.NET Web y el otro una Biblioteca de clases, como se muestra a continuación, no creen las carpetas que ahí se ven, yo les diré cuando crearlas, por el momento solo agreguen la del Model en la biblioteca de clases.
Model
Usando el Entity Framework podemos seguir dos caminos, el primero es crear el Model a partir de tablas en una base de datos y el segundo es crear las tablas a partir de clases existentes en nuestro proyecto, en esta ocasión vamos a usar el primero.
Tabla
Vamos a crear una tabla para almacenar empresas, con los siguientes campos:
Después agreguen manualmente algunas empresas, para que podamos testear la consulta.
Entity Framework
Al usar el Entity Framework para el proyecto simplificamos la codificación de nuestro Model, ya que la herramienta lo creara por nosotros, para poder concentrarnos en la parte complicada, aquí les dejo el link hacia un articulo previo donde explico cómo agregar un Model usando el Entity Framework, solo deben seguir esos pasos.
Coloquen el Model que creara el Entity Framework en la carpeta Model; esto lo pueden obtener, haciendo clic con el botón derecho del mouse sobre la carpeta Model, como se ve en esta grafica:
Contexto
Estamos usando el patrón Singleton y el patrón Service Locator para darle fortaleza a esta parte del código.
Como todo buen patrón necesitamos una Interface, la cual debe crearse dentro de la carpeta Interfaces:
Dentro del Model creen una carpeta que llamaremos Contexto, y dentro de esta agreguen esta clase que implementa la interface que acabamos de crear:
Es una forma muy simple del Service Locator, solo la parte que le corresponde al Singleton, simplemente verifica si no existe y lo crea, lo interesante es el uso genérico.
Acceso a datos
Usaremos el patrón de Repository que hemos ejemplificado en los otros ejemplos, para lo cual debemos crear una carpeta dentro de Model, denominada Interfaces y otra denominada Repositories.
En la carpeta de Interfaces colocaremos esta interface:
Fíjense que en el Namespace, he eliminado la parte que le añade VS y que corresponde a la carpeta donde colocamos la interface, esto me permite simplificar el acceso a lo vayamos creando dentro del Model; aun que se encuentren en diferentes carpetas, para organizar mejor los archivos, en código todo aparecerá dentro del mismo espacio de nombres.
Dentro de la carpeta Repositories colocaremos la clase que se encargara de la entidad empresa, la cual debe implementar nuestra interface Repository y la interface del sistema IDisposable, para que tengamos algo como esto:
Nuevamente observen el Espacio de nombres, subrayado en rojo; pero observen lo que está encerrado en azul, en esta línea se define una instancia de tipo IDataContext (que creamos previamente), la cual emplearemos para controlar la creación de las instancias de nuestro Model durante la ejecución de nuestra aplicación; el motivo es simple, queremos que la creación sea controlada y desde un solo punto.
A continuación les voy a presentar el código que está oculto en las regiones Grises.
Inyección de dependencia
Para asegurarnos que nuestro repositorio no sea cohesivo vamos a usar la inyección de dependencia, la cual tiene una participación muy interesante en la parte del constructor.
Si observan podrán ver que hay un constructor que no recibe parámetros y hay otro que recibe una instancia de nuestra clase HttpDataContext, de esta forma podemos garantizar que si el programador que usa nuestro repositorio desea cambiar esa parte, solo deberá implementar nuestra interface y codificarla según sus necesidades, sin que esto afecte a nuestro código; si por el contrario se limita crear la instancia sin enviarle una instancia, entonces mostros nos encargamos de enviarle una nueva instancia para que sea el nuestro el que emplee.
Implementación del Repositorio
Para esta parte usaremos LINQ ya que es una forma muy sencilla de realizar esta acción, nuestro ejemplo se limita por el momento a obtener todas las empresas que no estén de baja:
Por último la implementación del IDisposable
Este código contiene una llamada al destructor de la instancia, es la que empieza con un circunflejo:
Esta implementación es la recomendada por Microsoft, ya que nos permite realizar cualquier validación antes de llamar al método donde se solicita la participación del Garbage Collector.
Final de la Primera parte
En este punto hemos creado todo lo que necesitamos para el acceso a los datos, en nuestro articulo de mañana vamos a crear los servicios y en el siguiente la capa de presentación, ya falta poco.
Y recuerden: El poder del código solo es completo, si tenemos el conocimiento de cómo usarlo.
No hay comentarios:
Publicar un comentario