jueves, julio 21, 2016

No hagamos repositorios para el acceso a datos

Este artículo está pensado sobre todo para el desarrollo usando el .NET Framework. Quizás aplique para los demás también, ya que casi cada Framework tiene su ORM.

Hace ya varios años que leí la opinión de Ayende Rahien acerca de que el patrón repository era el nuevo singleton. Tiempo después Jimmy Bogard también escribió sobre alternativas.

A mi entender el patrón repository consiste en abstraer el acceso a datos para que el resto del código no tenga que lidiar con los detalles del acceso a datos (conexiones, consultas, SQL, etc) al momento de acceder a colecciones de datos.

Con  el creciente uso de ORMs el patrón repository ya no es necesario. Ahora podemos usar algo como Entity Framework y dejar que se encargue de esos detalles para los que construíamos un repositorio. Entity Framework (o cualquier ORM) hacen eso y más sin que tengamos que escribir tanto código de "plomería". Escribo este post porque aun veo a programadores que intentan usar el patrón repositorio aún y cuando están usando un ORM.


No veo la utilidad de abstraer la abstracción del ORM (como EF) bajo el patrón repository. No es necesario, es querer apegarse a un patrón de diseño solo porque antes se usaba. Sí, se usaba porque era necesario; pero ya no lo es. La meta no es usar patrones, la meta es tener software funcionando que sea fácil de modificar.

Escribí un poco sobre esto cuando traté el tema de la arquitectura en capas, aunque el artículo no se trataba precisamente del patrón repositorio.