2009-06-18 13 views
9

Tengo un repositorio (CustomerRepository) que recupera datos de la capa de datos. La mayor parte de la lógica empresarial está en la clase de entidad (Customer) que el repositorio acepta o devuelve.Patrón de repositorio y lógica comercial

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

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

Respuesta

19

Estoy de acuerdo con Robert Munteanu.

Básicamente, retoma la lógica de su negocio que no es inherente a su modelo en un nivel medio. El nivel medio es el nivel de negocio/objetos comerciales/capa de lógica de negocios/etc., pero solo se lo conoce como un nivel de servicio. No tiene que ser un servicio web, es un uso amplio del término servicio en el sentido de 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 adivinar por su nombre que está utilizando .net, y probablemente usando LINQ to SQL como su repositorio como se indica en NerdDinner.

El depósito normalmente devuelve IQueryable a la capa de servicio, lo que permite que la capa de capa de servicio reúna 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.

+1

El MVC Storefront de Rob Conery es lo que me llevó al patrón de repositorio, pero desafortunadamente ha refabricado la capa de servicios sin explicar realmente esa decisión en los videos. Entonces me preocupaba que tal vez esa no era la mejor manera. –

+11

Me enfrenté a un problema similar, ¿es esta la mejor arquitectura? Dejé de preocuparme por las interfaces con los contratos en la parte superior de la capa con las fábricas y solo me enfoqué en hacerlo funcionar. Encuentro con demasiada frecuencia que las personas están superando las soluciones de arquitectura. ¿El propósito es construir este momento de una base de código, un tributo a su propia fuerza y ​​perfección de capas y niveles? Creo que siempre que guardes tus datos en tu repositorio, tu "lógica de negocios" en los servicios de tu empresa y tus elementos de interfaz de usuario en tus Vistas, estás listo para empezar. Logre lo que se supone que debe hacer el software, refactorícese a medida que avanza – blu

+0

y logre el objetivo del software. – blu

5

Abróchelo detrás de un servicio.

+4

¿Qué significa eso en este caso? –

+0

Pienso que los servicios son un lugar para todo lo demás en el modelo de dominio. – Min

+1

De acuerdo. Crea CustomerService con algún método, donde actualices a todos tus clientes. – Gengzu

4

Colóquelo en otro repositorio (BusinessRuleRepository) y haga que CustomerRepository lo use.

O

Si la lógica de negocio sólo está limitando los resultados de un usuario puede ver es posible que desee utilizar un patrón de la 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.

0

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 que usan 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 mantengo en una capa de servicio y pasa los objetos del repositorio según sea necesario.

La ventaja añadida era 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.

Cuestiones relacionadas