Muchos de nosotros hemos utilizado herramientas para mapear del mundo relacional al mundo orientado a objetos tales como el Entity Framework y NHibernate. Sin duda el uso de estas herramientas esta motivado por la facilidad que se logra para trabajar con el acceso a datos. Sin embargo, a muchos de nosotros siempre nos queda una espinita acerca del uso de estas herramientas ya que a ratos quedan sensaciones un poco diferentes respecto a la eficiencia de las mismas. En mi caso personal, hasta antes del modelo Code First del Entity Framework no estaba del todo convencido de utilizar este ORM –> aunque Microsoft le quiera llamar de otra forma –> en un proyecto enterprise, ya que considero que los POCOS son parte fundamental en cualquier arquitectura que vayamos a utilizar por su eficiencia y porque podemos utilizarlos como “transportador” de objetos neutral, ya que al final estos objetos se serializan en tipos SOAP estándar que nos van a permitir que sean consumidos de forma simple desde otras tecnologías tales como Java y PHP –> claro, siempre y cuando usemos tipos estándar.
Definición
Sin embargo, desde hace un tiempo atrás me di a la tarea de buscar algo intermedio, que me permitiera tener algunas de las abstracciones de lo ORM, pero que no me castigara en desempeño y me encontré el término Micro ORM. Un micro ORM es por lo general una librería pequeña que abstrae la funcionalidad principal de ADO.NET a través de un uso extensivo de los tipos dinámicos. Esto permite tener la misma funcionalidad que con ADO.NET tradicional, pero con mucho menos código; todo esto sin perder desempeño.
Ejemplo
Para ilustrar el concepto vamos a crear un ejemplo sencillo en el cual vamos a agregar, buscar y eliminar un registro desde una tabla en una base de datos SQL Server, este ejemplo lo vamos a desarrollar con Dapper.NET. La tabla que vamos a utilizar es la siguiente:
Como comenté anteriormente, los Micro ORM basan su funcionalidad en los POCOS, por lo tanto vamos a crear una librería que será nuestra capa de entidades –> siempre importante separar el estado del comportamiento. EL POCO para la tabla empresa es el siguiente:
Ahora procedemos con la capa de acceso a datos. En esta capa vamos a crear métodos estáticos para Agregar, Obtener y Eliminar empresas. Recuerden que en esta capa utilizamos métodos estáticos porque no existe razón alguna para mantener estado en estas invocaciones. Nótese que la hilera de conexión está en el archivo, algo que no es una recomendación pero un “abuso” propio para poder desarrollar el ejemplo de una manera más sencilla.
En el código anterior se puede ver que para hacer un select sobre una tabla utilizamos el método de extensión genérico Query, el cual recibe un arreglo de parámetros –> aunque esta sobre cargado para recibir más parámetros tales como transacciones –> y retorna un conjunto de datos tipificado en base al tipo enviado por parámetro en el método query –> en el generic.
Igualmente para ejecutar sentencias SQL que no retornan conjuntos de datos pero que llevan a cabo acciones sobre las tablas como el eliminar o el agregar vamos a utilizar el método Execute. Este método al igual que el Query, es un método de extensión que para este ejemplo, recibe una colección de parámetros los cuales por orden son asignados a los parametros definidos con @ dentro de la sentencia SQL; por ejemplo @Nombre –> Nombre = pEmpresa.Nombre.
Ahora procedemos a crear una capa de negocios que simplemente tiene las llamadas respectivas a la capa de acceso a datos.
Si queremos exponer estos métodos de lógica de negocio, vamos a tener que marcar como serializables los campos del POCO y el POCO utilizando el serializador de WCF.
Luego procedemos a crear el servicio. El primer paso es crear una librería WCF y definir el contrato del servicios
Después procedemos a implementar el contrato del servicio
Si queremos consumir el servicio desde cualquier interface, simplemente agregamos la referencia al servicio recién creado y a través del proxy se generarán los tipos necesarios para ejecutar nuestra aplicación.
