Patrón de repositorio y múltiples entidades centrales u objetos comerciales relacionados: ¿un depósito o más?

Question

Estoy buscando implementar el patrón de repositorio (ya que lo que se me ocurrió fue un 90% de implementación de todos modos), y me encontré con una pregunta de diseño, donde tengo dos o más objetos comerciales básicos (por ejemplo, Negocios y Contacto en una aplicación de CRM), las BO pueden estar estrechamente relacionadas o no estar relacionadas en absoluto.

En esta situación, debería implementar un repositorio (CrmRepository por ejemplo, con .addBusiness(), .addContact() y otros), o varios repositorios (BusinessRepository, ContactRepository cada uno con su propio .add(), .delete() y otros).

¿Cuál es la mejor práctica en esta situación?

El DAL subyacente es EF4.

Saludos

Moo

Answer 1

Hemos estado haciendo un montón de ideas recientemente en mi trabajo y encontré algunos artículos que nos ayudó a visualizar y diseño de nuestros repositorios de una manera consistente.

Según lo que descubrimos, una de las mejores prácticas es crear un repositorio por raíz agregada. Una raíz agregada sería un tipo de entidad donde necesita hacer referencia a ese tipo de entidad para llegar a los tipos de valores secundarios. Solo se podría consultar un tipo de entidad desde la base de datos y cualquier tipo de valor secundario debería atravesarse desde la entidad.

Con su información en su pregunta, parece que un Negocio sería una raíz agregada y, por lo tanto, un Tipo de entidad y requeriría su propio repositorio. Dado que Contact puede vivir independientemente, también podría ser una raíz agregada. Ambos objetos pueden tener referencias entre sí y usar un repositorio para cargar las empresas desde un contacto o cargar los contactos de una empresa a través de su repositorio respectivo.

He estado leyendo mucho recientemente, así que espero haber tenido algún sentido en mi proceso de pensamiento.

Algunos enlaces

Aggregate Root

Entities, Value Objects, Aggregates and Roots

Answer 2

estoy totalmente de acuerdo con Mark en esto, pero para añadir un poco más. A medida que observa los beneficios de crear un repositorio genérico, el patrón común es IRepository y Repository. Una cosa que he encontrado que es mucho más útil, sacada a la luz por Jeremy D. Miller (no puedo encontrar la referencia) es tener genéricos en el nivel de método.

Así que mi IReposity tendrá métodos como éste:

T FindByKey<T>(int key); 
IEnumerable<T> FindAll(); 
T FindBy<T>(System.Linq.Expressions.Expression<Func<T, bool>> expression); 
void Update<T>(entity); 

Luego, dependiendo de su filosofía, se puede pasar alrededor de la clase repositorio y consultar directamente, o hacer su resumen aplicación repositorio y forzar su uso a ser encapsulado por un repositorio explícita, así:

CrmRepository : Repository 
{ 
    FindByCustomerId(int customerId) 
    { return FindByKey<Customer>(customerId);} 
}