Patrón de repositorio y lógica de negocios

Question

Tengo un repositorio ( CustomerRepository ) que recupera datos de la capa de datos. La mayor parte de la lógica de negocios está en la clase de entidad ( Cliente ) que el repositorio acepta o devuelve.

Sin embargo, ¿dónde coloca la lógica empresarial de la entidad global (que se aplica a todos los clientes)?

Por ejemplo, es posible que no quiera devolver a todos los clientes a ciertos usuarios. No quiero poner esa lógica en el repositorio.

Answer 1

Estoy de acuerdo con Robert Munteanu.

Básicamente, usted acumula su lógica empresarial que no es inherente a su modelo en un nivel medio. El nivel medio es el nivel de negocios / objetos de negocios / capa de lógica de negocios / etc., pero solo se conoce como un nivel de servicio. No tiene que ser un servicio web, es un uso amplio del término servicio, ya que agrega la funcionalidad de un área de aplicación específica.

Básicamente, tendría una clase CustomerService que contiene la referencia del repositorio. Su capa de presentación haría referencia a la clase de capa de servicio.

Hay una distinción adicional que se puede hacer como una suposición de su nombre que está usando .net, y probablemente usando LINQ to SQL como su repositorio como se describe en NerdDinner.

El repositorio generalmente devuelve IQueryable a la capa de servicio, lo que permite que la capa de servicio encadene múltiples consultas para crear diferentes conjuntos de resultados. El Servicio luego evalúa la expresión usando ToList u otro método similar y lo devuelve a la capa de presentación.

Answer 2

Envuélvelo detrás de un servicio.

Answer 3

Póngalo en otro repositorio (BusinessRuleRepository) y haga que CustomerRepository lo use.

O

Si la lógica de negocios solo limita los resultados que un usuario puede ver, es posible que desee utilizar un patrón de Fachada con una fábrica. En este caso, tendría un ICustomerRepository que maneja su CustomerRepository y LimitedCustomerRepository (que podría encapsular CustomerRepository), y un CustomerRepositoryFactory que devuelve el ICustomerRepository apropiado para el usuario.

Answer 4

Creo que separar este tipo de funciones en una capa de servicio es el camino a seguir.

Recientemente construí un sistema para hacer pronósticos complejos con muchas entidades utilizando datos históricos. Poner todos los bits de acceso a datos en el repositorio para cada entidad. La intrincada lógica de pronóstico que mantuve en una capa de servicio y pasé los objetos del repositorio según sea necesario.

La ventaja adicional fue que tenía una manera fácil de exponer toda la lógica de pronóstico a sistemas externos simplemente creando una capa de API web.