EL patron de Diseño Repositorio

EL patron de Diseño Repositorio

El patrón repositorio es una construcción común para evitar la duplicación de la lógica de acceso de datos a través de nuestra aplicación.

Esto incluye el acceso directo a una base de datos, ORM, DataServices WCF, archivos xml, etc.

El único objetivo del repositorio es para ocultar los detalles del acceso a los datos.

Podemos consultar fácilmente el repositorio de objetos de datos, sin tener que saber cómo proporcionar cosas como una cadena de conexión.

El repositorio se comporta como una recopilación de datos de libre acceso en memoria a las que podemos añadir, borrar y actualizar objetos.

El patrón Repositorio añade una capa de separación entre las capas de datos y de dominio de una aplicación.

También facilita el testing de los módulos de acceso a datos de una aplicación.

¿Qué diferencias tiene con el patrón DAO?

Respuesta corta:

Repositorio es un patrón de Diseño orientado a Dominio (DDD). Repositorios sirven para obtener o conservar Entidades o, para ser más específico, las Raíces de los Agregados

Los Data Access Objects sirven para rescatar o persistir los datos, generalmente en forma de Data Transfer Object (DTO).

Enfoque de Repositorios es Dominio y enfoque de los DAO es persistencia de los datos.

Respuesta larga:

La diferencia entre los dos patrones ilustra bien la diferencia entre modelo tradicional de construir aplicaciones empresariales (originado en J2EE), orientado a resolver problemas técnicos, y el modelo DDD.

En DDD, los objetos de dominio son “objetos de verdad”, tienen comportamiento que tiene sentido de punto de vista de dominio (o también “negocio” como dirían aquellos que creen que software siempre se construye en contexto de algún “negocio”). En este sentido, el Repositorio también existe de punto de vista de dominio, es el objeto que permite obtener y conservar las Entidades. Las entidades tienen los datos y los métodos que operan sobre estos datos, pero de punto de vista de negocio. La diferencia es muy notoria cuando comparas el DTO con patrón Entidad en DDD.

En modelo DAO/DTO, los DTO son estructura de datos “tontas” sin comportamiento. Los DAO entonces, van a tener los métodos típicos CRUD y muchas veces van a permitir acceso a diferentes entidades “directamente” a las cuales en DDD se accede siguiendo las asociaciones desde la raíz de agregado.

Investigar y dar ejemplos sencillos de:

- Bases de Datos Orientadas a Objetos

En una base de datos orientada a objetos, la información se representa mediante objetos como los presentes en la programación orientada a objetos. Cuando se integra las características de una base de datos con las de un lenguaje de programación orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS, object database management system). Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programación en uno o más lenguajes de programación a los que dé soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma transparente, control de concurrencia, recuperación de datos, consultas asociativas y otras capacidades.

Las bases de datos orientadas a objetos se diseñan para trabajar bien en conjunción con lenguajes de programación orientados a objetos como Java, C#, Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que estos lenguajes de programación.

Los ODBMS son una buena elección para aquellos sistemas que necesitan un buen rendimiento en la manipulación de tipos de dato complejos.

Los ODBMS proporcionan los costes de desarrollo más bajos y el mejor rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen una integración transparente con el programa escrito en un lenguaje de programación orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.

- Bases de Datos orientadas a grafos

Una base de datos orientada a grafos(BDOG) representa la información como nodos de un grafo y sus relaciones con las aristas del mismo, de manera que se pueda usar teoría de grafospara recorrer la base de datos ya que esta puede describir atributos de los nodos (entidades) y las aristas (relaciones).

Una BDOG debe estar absolutamente normalizada, esto quiere decir que cada tabla tendría una sola columna y cada relación tan solo dos, con esto se consigue que cualquier cambio en la estructura de la información tenga un efecto solamente local.

Ventajas

Las BDOG también ofrecen servicios nuevos o mejorados como:

• Consultas más amplias y no demarcadas por tablas (ejemplo “Muestre todas las tablas que posean un nombre Carlos”).

• No hay que definir un número determinado de atributos (una persona puede tener relacionados cuatro nombres mientras que otra solamente dos, sin desperdiciar espacio).

• Los registros también son de longitud variable, evitando tener que definir un tamaño y también posibles fallas en la base de datos.

• Se puede recorrer directamente la base de datos de forma jerárquica, obtener el nodo abuelo del nodo y viceversa.

Desventajas

• La búsqueda de nodos en diferentes máquinas puede ralentizar el proceso drásticamente.

• Requiere un cambio conceptual para los desarrolladores, por lo que implica una curva de aprendizaje.

Algunos casos de uso

• Seguimiento de las fuentes de comida, desde su recogida hasta la mesa (Objectivity, Inc.)

• Aplicaciones de colocación de anuncios.

• Gestión de red.

• Genealogía.

Listado de bases de datos orientadas a grafo

• AllegroGraph: escalable y de alto rendimiento.

• Bigdata: RDF/base de datos orientada a grafo.

...