ASP.NET MVC: ¿Cuántos repositorios?

Question

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.

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?

Answer 1

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

Answer 2

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); 

Answer 3

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 ...

Answer 4

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.

Answer 5

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

).

Answer 6

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

Answer 7

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.

Answer 8

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.