Patrón Generic Repository

Un apunte para que no se me olvide donde estan las ideas claves.

El Patrón Modelo de Dominio

En un diseño orientado al modelo de datos, comenzamos por diseñar la base de datos para después crear los componentes de negocio.
Cuando la complejidad del sistema crece, nuestro enfoque en los datos deja de tener importancia ya que debemos centrarnos en la funcionalidad y es entonces cuando un diseño orientado a datos deja de ser escalable.
El patrón modelo de dominio nos permite centrarnos en el comportamiento del sistema y en el flujo de datos que lo hace funcionar, además nos ayuda a obtener un modelo de objetos que es una representación del modelo conceptual del sistema.
El modelo de dominio describe las entidades que participan en el sistema, las relaciones y el flujo de datos que existe entre ellas, dichas entidades se mapean en clases que se componen de propiedades y métodos.
Un modelo de dominio es independiente de la base de datos y por tanto podemos reutilizarlo en otras aplicaciones.
Sin embargo el patrón modelo de dominio tiene un alto coste inicial, aunque a cambio ganamos un comportamiento lineal con respecto al aumento de la complejidad.
A diferencia de un diseño orientado al modelo datos, el diseño orientado al dominio es dirigido por los requerimientos y nos obliga a entender las reglas que definen el negocio y a modelarla a través de clases.

Patrón “Repository”
La primera vez que oímos hablar del patrón “Repository” fue en el famoso libro de Martin Fowler, Patterns of Enterprise Application Architecture, y la autoría se le atribuye a Edward Hieatt y Rob Mee.

Un repositorio es una clase que servirá como intermediario entre nuestra aplicación y nuestros datos, dicho con otras palabras, será una clase que nos ofrecerá una interfaz CRUD (Crear, Obtener, Actualizar, Borrar (Create, Read, Update, Delete)).

En este enlace hay un articulo muy bueno sobre este patron repository
http://blog.foxandxss.net/patron-repository
http://programandonet.com/web/patrones-de-diseo-repository/
http://kartones.net/blogs/coco/archive/2009/12/03/la-capa-de-negocio-vi-el-patr-243-n-modelo-de-dominio.aspx

Sobre inyeccion de dependencias
http://blog.foxandxss.net/dependency-injection-indice

Patrón Unit of Work (UoW) o Unidad de Trabajo

Hace tiempo que iba detrás de este patrón y aquí hay un post muy clarito de para qué sirve y como se usa,  en este otro post hay una versión mas extensa del mismo patrón, y en este post también hay un estudio del mismo patrón

 

Este patrón tiene como objetivo tratar como una Unidad todos aquellos objetos nuevos, modificados o eliminados con respecto de una fuente de datos. Se utiliza para trabajar con un conjunto de objetos persistentes que deben tratarse como una "unidad" de trabajo, almacenándose en una base de datos de manera atómica. Este patrón es el encargado de hacer el seguimiento de todos aquellos objetos que son nuevos, y que por lo tanto deben guardarse en la base de datos, de todos los objetos que han sido modificados y que deben actualizarse en la base de datos y de todos los que han sido borrados y deben quitarse de la base de datos.

Martin Fowler, ya realizó una descripción de UoW en su libro “Patterns of Enterprise Application Architecture”.