2009-09-24 18 views
9

Estoy en proceso de diseñar un sitio web en ASP.NET MVC y quizás estoy un poco confundido en cuanto a la naturaleza exacta de un repositorio.ASP.NET MVC: ¿Cuántos repositorios?

Siguiendo el ejemplo de NerdDinner, mi sitio debe tener un repositorio que sirva las entidades cuando las necesite. Sin embargo, también he escuchado que debe tener diferentes repositorios que tratan con conjuntos específicos de entidades relacionadas ....?

En el caso de mi sitio, habrá un número de entidades (alrededor de 15 tablas) pero la mayoría están relacionadas. ¿Está bien/es aconsejable tener un repositorio que contenga todos los métodos que necesitaré para tirar/actualizar/eliminar, etc. o debería dividirlos?

Respuesta

2

que crear un repositorio para cada objeto de datos.

Por ejemplo, una base de datos sencilla biblioteca podría contener los siguientes depósitos:

  • AuthorRepository
  • BookRepository
  • PublisherRepository
+0

entonces en este caso, ¿qué repositorio devolvería todos los libros por un autor específico? – Sergio

+0

El repositorio de libros, ya que está solicitando libros – jao

+1

veo. Tal vez estoy pensando en esto de la manera incorrecta, pero parece extraño ... en términos de entidades (marco de entidad en mi caso) no puedo ayudar, pero creo que si tengo el autor, entonces tengo los libros (libros de autor, por ejemplo) . Entonces, en ese sentido, parece extraño dividirlos en diferentes repositorios. – Sergio

5

Si utiliza un repositorio genérico que acepta tipos, entonces no veo ninguna razón para usar más de uno.

que utilizan una interfaz de esta manera:

public interface IRepository 
{ 
    void Save<ENTITY>(ENTITY entity) 
     where ENTITY : Entity; 

    void Delete<ENTITY>(ENTITY entity) 
     where ENTITY : Entity; 

    ENTITY Load<ENTITY>(int id) 
     where ENTITY : Entity; 

    IQueryable<ENTITY> Query<ENTITY>() 
     where ENTITY : Entity; 

    IList<ENTITY> GetAll<ENTITY>() 
     where ENTITY : Entity; 

    IQueryable<ENTITY> Query<ENTITY>(IDomainQuery<ENTITY> whereQuery) 
     where ENTITY : Entity; 

    ENTITY Get<ENTITY>(int id) where ENTITY : Entity; 

    IList<ENTITY> GetObjectsForIds<ENTITY>(string ids) where ENTITY : Entity; 

    void Flush(); 
} 

luego usar en código como este:

var returnedObjects = repository.GetAll<ObjectClass>(); 
var singleObject = repository.Get<ObjectClass>(id); 
2

Creo que tal vez la verborrea de lo que es un repositorio que puede ser confuso. Para mí, un repositorio es el almacenamiento de datos (es decir, la base de datos MS SQL) donde se almacenan sus datos.

Después del Repository Pattern, recomiendo configurar un único repositorio para cada almacén de datos. La mayoría de mis proyectos utilizo MS SQL, así que creo un repositorio para esa base de datos (me gusta usar Subsonic para mi DAL/ORM y también implementa el patrón Repositry y el patrón ActiveRecord) luego creo fábricas para cada tabla. Esto me permite resumir las clases de Subsonic ActiveREcord y me da abstracción.

Esperanza eso es útil, tal vez ...

+0

Tengo curiosidad acerca de la declaración de creación de un repositorio para cada almacén de datos. ¿Qué sucede si tengo una "entidad" de varios a muchos que no hace más que almacenar 2 ID (como su clave principal)? ¿Debo crear un repositorio a partir de eso, o puedo simplemente incluir algunos de los métodos básicos de búsqueda/guardado en otro repositorio relacionado? Pensé que los repositorios deberían enfocarse más en las entidades agregadas. – CitizenBane

+0

Gracias por todas las respuestas chicos - muy útil. Esta ruta 'genérica' me tiene interesada, aunque siendo la principiante que soy no estoy segura de cómo voy a configurarlo. Estoy usando el marco de la entidad como mi ORM .... – Sergio

8

utilizo un genérica repositorio que es suficiente para muchos entidades.

Para una más compleja, simplemente extienda esto con lo que se necesita. Lo mejor de ambos mundos realmente.

8

En el diseño impulsado por dominio, existe una regla de que los repositorios son por raíz agregada. Puede leer más al respecto here.

Cuanto más leo, más pienso que NerdDinner se ve a menudo como una colección de buenas prácticas, mientras que no lo es (ver here para una discusión sobre, particularmente, el repositorio de NerdDinner).Es por eso que la gente a menudo culpan a otros ejemplos de EM como Oxite (y here:

Desarrolladores acuden a ella, el elogio , y ciegamente aceptarlo como un evangelio porque viene de Microsoft (es ya en camino). Por desgracia, cualquier desarrollador que adopta su espíritu quedar con un desorden unmaintainble, no comprobable e ilegible

).

+1

Bueno, cierto ... –

+0

+1 primer enlace muy bueno! –

0

Tiendo a usar un repositorio por grupo de entidades relacionadas. es decir, orderrepository podría tener:

Orden y OrderDetail.

y tendría otra para, por ejemplo, al cliente, CustomerProfile, etc.

Esto mantiene las clases de repositorios ordenada.

Davy

1

Queen3 es adecuado, se puede seguir la teoría de que la raíz agregada. Básicamente, agrupo mi repositorio no pensando en Entidades, sino cómo se agrupan lógicamente en la aplicación que estoy construyendo.

Por ejemplo:

CustomersRepository 
OrdersRepository 
... 

En CustomerRepository pondría métodos para GetCustomers, GetCustomer, AddCustomer, DeleteCustomer, AddCustomerContact, DeleteCustomerContact.

En OrdersRepository pondría métodos para GetOrders, GetOrder, AddOrder, CancelOrder, CloneOrder, AddOrderDetail, DeleteOrderDetail y más.

2

No debe crear repositorios para cada tabla. Como dijo queen3, deberías crear Repository por raíz agregada. Por ejemplo, si los productos pueden tener una categoría, el repositorio de categoría debe ser una clase anidada de productos. Siga la relación lógica de dominio que los objetos de dominio.