trabajo - repositorio base c#
Patrón de repositorio y múltiples entidades centrales u objetos comerciales relacionados: ¿un repositorio o más? (2)
Estoy considerando la implementación del patrón de repositorio (ya que se me ocurrió una implementación del 90%), y he encontrado una pregunta de diseño, en la que tengo dos o más objetos de negocio principales (por ejemplo, Negocios y Contacto en una aplicación de CRM), los BO''s pueden estar fuertemente relacionados o no estar relacionados en absoluto.
En esta situación, debo implementar un repositorio (CrmRepository por ejemplo, con .addBusiness (), .addContact () et al), o múltiples repositorios (BusinessRepository, ContactRepository, cada uno con su propio .add (), .delete () et al ).
¿Cuál es la mejor práctica en esta situación?
El DAL subyacente es EF4.
Saludos
Mugir
Estoy totalmente de acuerdo con Mark en esto, pero para agregar un poco más. Al observar los beneficios de crear un repositorio genérico, el patrón común es IRepository y Repository. Una cosa que he encontrado para ser 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 este:
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, puede pasar la clase Repository y consultarla directamente, o hacer que la implementación de su Repository sea abstracta y forzar su uso para ser encapsulado por un repositorio explícito, como este:
CrmRepository : Repository
{
FindByCustomerId(int customerId)
{ return FindByKey<Customer>(customerId);}
}
Hemos estado pensando mucho recientemente en mi trabajo y encontramos algunos artículos que nos ayudaron a visualizar y diseñar nuestros repositorios de manera consistente.
De 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 en la que necesita hacer referencia a ese tipo de entidad para alcanzar tipos de valor secundarios. Solo se podría consultar un tipo de Entidad desde la base de datos y cualquier tipo de Valor secundario tendría que atravesarse desde la Entidad.
Con su información en su pregunta, parece que una empresa sería una raíz agregada y, por lo tanto, un tipo de entidad y requeriría su propio repositorio. Como Contact puede vivir independientemente, también puede ser una raíz agregada. Ambos objetos podrían tener referencias entre sí y usar un repositorio para cargar los Negocios de un Contacto o cargar los Contactos de un Negocio a través de su respectivo repositorio.
He estado leyendo mucho recientemente, así que espero que tenga algún sentido en mi proceso de pensamiento.
Algunos enlaces