2012-04-23 20 views
8

En mi aplicación asp.net mvc 3, estoy usando el patrón de repositorio. Tengo 3 entidades, empresa, país, ciudad. Cada uno de ellos tiene su propio repositorio. La entidad de compañía tiene claves extranjeras FoundedCountry y FoundedCity. Ahora en una vista, quiero mostrar los detalles de la empresa. En esta vista, quiero ver los detalles de la Compañía, así como el nombre de FoundedCountry y el nombre de FoundedCity. En mi opinión, tengo que manejar esto con una especie de consulta JOIN. Pero estoy atascado en cómo lograr esto en el patrón de repositorio. ¿Cómo puedo manejar este JOIN en el patrón de repositorio?¿Cómo puedo consultar tablas cruzadas con el patrón de repositorio?

Gracias.

Respuesta

4

El repositorio debe tener una interfaz basada en tareas. Esto significa que ORM's, join, etc. están dentro del repositorio. La aplicación solo ve una interfaz que devuelve un objeto que puede usar.

Esto significa que no se crea un repositorio alrededor de una mesa (prácticamente no tiene sentido). En su escenario, sugiero que tenga (al menos) 2 repositorios: uno se encargará de todo lo relacionado con la actualización del modelo y el otro solo leerá (consultas).

Esto significa que el repositorio de consultas devolverá solo los datos que desee (básicamente devuelve los bits del modelo de visualización). Por supuesto, las tablas y uniones reales son un detalle de implementación del repositorio.

+0

"Esto significa que no crea un repositorio alrededor de una tabla (más o menos derrota el propósito) ". Por lo que sé, tengo que crear un repositorio para cada entidad. De su comentario, creo que tengo que agregar otro repositorio que manejará consultas complejas. ¿Derecha? – SherleyDev

+0

No :). No 'tiene que' crear un repositorio para cada entidad. El repositorio básicamente oculta todo lo relacionado con la base de datos del resto de la aplicación. Dentro del repositorio puedes usar entidades, EF o Nhibernate, no importa. El repositorio usa internamente el orm, en su caso las entidades y luego devuelve los objetos que la aplicación comprende. Las entidades mismas ya son una abstracción utilizada por el repositorio. – MikeSW

+0

En el siguiente tutorial dice "En este tutorial, implementará una clase de repositorio para cada tipo de entidad". Lo estaba siguiendo. http: //www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementation-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application – SherleyDev

2

¡No construya su patrón de repositorio de forma que evite las uniones! Esto generalmente significa usar el mismo contexto ORM (DataContext/ObjectContext) para todas las instancias asociadas con la solicitud HTTP actual.

Considero que es un anti-patrón tener un IRepository genérico porque el acceso a la base de datos rara vez está restringido a un solo tipo de entidad al mismo tiempo.

Podría considerar el DataContext/ObjectContext como un repositorio por sí mismo.

Un último consejo: si no sabe para qué sirve la abstracción de un repositorio, no use una.

+0

No estoy de acuerdo con una cosa: que el Contexto de datos se deba considerar como un repositorio. Mientras que el DC abstrae el acceso db y sql, todavía está atado con un rdbms e IMO, es una abstracción con filtraciones en el mejor de los casos. – MikeSW

+0

Si un ORM es una abstracción con fugas, ¿qué tan permeable es un repositorio personalizado? Es un tamiz Al mismo tiempo, le impide acceder a todo el poder del ORM (que es la naturaleza de una abstracción). – usr

+0

Un repositorio diseñado correctamente no tiene fugas porque no expone los detalles de implementación, como un ORM. El repositorio utiliza toda la potencia del ORM, es su trabajo. El resto de la aplicación no tiene la función de conocer o utilizar el orm. Consulte esta publicación http://www.sapiensworks.com/blog/post/2012/04/15/The-Repository-Pattern-Vs-ORM.aspx – MikeSW

Cuestiones relacionadas