MVC - Domain Service se encarga de filtrar o ¿Capa de repositorio?

Question

¿Debería estar filtrando mis resultados IQueryable del Servicio de dominio?

Por ejemplo ... Mis 3 portales (sitios web) acceder a la misma capa de servicios de dominio, dependiendo del tipo de usuario que es, que yo llamo un método repositorio específico y devolver el resultado,

actual capa de repositorio:

IQueryable<Products> GetAllProductsForCrazyUserNow(CrazyUser id); 
    Products GetAProductForCrazyUserNow(CrazyUser id,product id); 

    IQueryable<Products> GetProductsForNiceUserNow(NiceUser id); 
    Products GetProductsForNiceUserNow(NiceUser id,product id); 

¿sería mejor simplemente hacer esto en la capa de repositorio:

IQueryable<Products> GetAllProducts(); 
    Products GetAProduct(product id); 

Luego, dentro del Servicio de dominio, lo hago sencilla el filtro es decir

var Niceman = IQueryable<Products> GetAllProducts().Where(u=> u.Name == "Nice"); 

NOTA: Tengo una sesión de solo lectura y una sesión que incluye CRUD dentro de la capa de repositorio, así que tenga esto en cuenta al responder.

Segunda pregunta: ¿Debo hacer algún tipo de filtrado en la capa de servicio del dominio? Esta misma capa es la única capa que puede modificar la Entidad, es decir, Product.Price == 25.00; Esto no se delega en la capa de repositorio.

Answer 1

Normalmente utilizo la capa de repositorio para hacer un simple trabajo CRUD y hacer que la capa de dominio realice cualquier lógica comercial o en su caso cualquier filtrado que sea necesario antes de pasar esos datos de vuelta a la capa UI.

Separar la lógica empresarial/de filtrado de la capa de repositorio ayudará a mantener las cosas limpias. Además, en el futuro si se mueve a un tipo diferente de patrón de acceso a datos, entonces no tendrá que cambiar la forma en que funciona ese código, ya que estará separado en su capa de dominio.

Answer 2

Haroon,

I utilizar métodos de extensión en IQueryable<Classes> EXTERIOR del repositorio. De hecho, tengo un conjunto de clases que yo llamo 'Filtros' y ellos son por lo general algo en este sentido:

public static class ProductFilters 
{ 
    public static IQueryable<Products> NiceMan(
     this IQueryable<Products> customQuery, string filterName) 
    { 
     if (!string.IsNullOrEmpty(filterName)) 
      customQuery = customQuery.Where(u => u.Name == filterName); 
     return customQuery; 
    } 
    // create lots of other Products based filters here 
    // and repeat with seperate IQueryable<Classes> per type 
} 

uso:

var Niceman = IQueryable<Products> GetAllProducts().NiceMan("Nice"); 

Me parece una buena separación de la lógica y mantiene el repositorio limpio Y en respuesta a la segunda pregunta, sí, use esta lógica de filtro/extensión dentro de la capa de servicio, en lugar del repositorio también.

Answer 3

He tenido la misma pregunta yo mismo. Mi duda al ponerlo en la capa de servicio fue que en algunos casos el proceso de filtrado podría eliminar la mayor parte de los registros devueltos del repositorio, y no quería obtener más datos de los necesarios de la base de datos.

Terminé mudándome a NHibernate, y mis métodos de repositorio aceptaron DetachedCriteria argumentos. Luego pasé la información del usuario a la capa de servicio y le pedí que realizara el filtrado no manipulando un IQueryable sino construyendo un objeto DetachedCriteria y pasándolo al repositorio, modificando así el SQL y limitando el trabajo de la base de datos.

Hasta ahora parece funcionar bastante bien, y "se siente" bien, ya que tengo mi lógica bastante sólida en la capa de servicio con el repositorio solo haciendo CRUD básico.