Organización de clases con el patrón de diseño del repositorio

Question

Comencé a actualizar una de nuestras aplicaciones de software internas, escritas en formularios web ASP.NET y pasando a ASP.NET MVC.

Estoy tratando de aprovechar el patrón de diseño del repositorio para mis clases, lo que me lleva a mi pregunta sobre cuánto poner en un repositorio.

Tengo las siguientes entidades:

• Tema
• Comentarios Tema (Tema puede tener múltiples comentarios)
• revisiones de tema (cada vez que un tema se edita, se registró una revisión)
• Suscripciones a temas (permite a los usuarios suscribirse a los cambios para un tema en particular )

Actualmente tengo una interfaz para ITopicRepository y una clase llamada TopicRepository que maneja todo el CRUD básico para un tema. Ahora me estoy preparando para agregar el código de Comentarios, Revisiones y Suscripciones.

Me pregunto, ¿TODO esto va al TopicRepository O CREO un repositorio para cada una de las entidades, por ejemplo, TopicRevisionRepository y así sucesivamente.

Answer 1

Hay una desconexión bastante sustancial entre la estrategia de acceso a datos MVC promedio y la comprensión del diseño del dominio del patrón de repositorio.

La mayoría de las muestras que verá para ASP.Net MVC están apenas un paso más allá de ActiveRecord, utilizando objetos de repositorio por entidad. Lo que realmente están implementando es una especie de Table Data Gateway, y usa la palabra Repository en lugar de Gateway.

No hay nada de malo en eso para muchas aplicaciones, y generalmente he comenzado nuevas aplicaciones con el mismo enfoque hasta que pueda probar que necesito algo diferente. Sin embargo, los principios de Diseño Dirigido por Dominio, de los cuales generalmente se toma prestada la idea del repositorio, deberían identificar Raíces agregadas y consolidar el acceso a los datos para esas entidades secundarias a través del repositorio agregado de la raíz.Esto le permite establecer límites en torno a los cambios de estado en su almacén de datos, y puede ayudar a hacer cumplir los cambios transaccionales, entre otras cosas.

Editado para agregar: en su ejemplo, parece muy poco probable que modifique cualquiera de estos objetos secundarios de forma aislada del padre, por lo que me sentiría tentado a decir que un "tema" es una raíz agregada para Tu dominio.

Answer 2

En mi opinión, debería entrar en su propio repositorio ...

Editar:

media entre el dominio y datos capas de mapeo utilizando una interfaz similar a la colección para acceder dominio objetos.

Repository Pattern

Esto permite que si te interesa utilizar un repositorio genérico como this example lo que significa menos código ...

Answer 3

Mirando el NerdDinner tutorial, parecen ir con un repositorio por entidad.

Cuando lo piensas bien, tiene sentido. Habrá casos en los que desee tener control sobre cuándo cargar subentidades.

Answer 4

Creo que depende de cómo va a acceder a sus datos. Los cambios siempre mirarán un tema con sus comentarios y viceversa para elementos de IU de comentarios similares.

Por lo tanto, su tema se convierte en Aggregate Root y solo necesita un único repositorio para este enfoque.

Una cosa a considerar es que si tiene muchas cosas pequeñas a las que solo necesita un acceso muy limitado como una lista de opciones para un menú desplegable, realmente no quiere un repositorio completo para eso. El problema es que una vez que pasas 20 entidades terminarás teniendo 20 interfaces y 20 repositorios para pensar en tu solución.

Es muy pragmático tener solo repositorios para sus raíces agregadas y mantener juntos otros repositorios de tipo de valor. Por ejemplo, un DropdownlistRepository o algo así.

Finalmente, en la etapa de su proyecto las preocupaciones sobre el rendimiento simplemente no importan y la recuperación de un gráfico de objetos completo para el "Tema" probablemente no sea tan malo en cuanto al rendimiento. Mantenga las cosas simples, si usa un mapeador ORM debería poder administrarle el Tema cada vez que lo necesite con todas sus entidades secundarias cargadas perezosamente.