clases de lógica de negocios de nomenclatura

Question

que tienen una capa de negocio que tiene algunos objetos de negocio/POÇOS/entidades/lo que sea. También tengo algunos repositorios para el acceso a los datos. Hasta este punto, he estado accediendo a los repositorios directamente desde mi capa de interfaz de usuario. Estoy en un punto en el que realmente necesito más clases que no sean directas CRUD, así que voy a crear algunas clases de lógica de negocios que harán la lógica, y CRUD y los repositorios no serán accedidos por el IU nunca más (lo que probablemente debería haberse hecho desde el principio).

¿Qué debo llamar a estas clases? Lo único que puedo pensar son clases de servicio, pero tengo servicios WCF reales en esta aplicación, así que eso lo hará confuso. Los servicios de WCF también utilizarán estas clases, por lo que tener un servicio de usar una clase de servicio parece extraño y confuso.

Answer 1

uso el "Servicio" convención de nombres también. Es cierto que el "servicio" se ha convertido en un término muy sobrecargado en la industria, pero tiene más sentido. Los desarrolladores de revisar el código debe ser capaz de determinar la diferencia entre una aplicación/servicio de dominio frente a un servicio WCF, y mientras tiene una llamada de servicio WCF otras clases de servicios pueden parecer confuso, creo que usted encontrará que no lo es. La idea de un servicio es que es un código que realiza una función y está disponible para su uso por otro código. Podría ser un servicio interno, o podría ser un servicio expuesto externamente a través de http o lo que sea. Pero la idea de lo que hace el código es la misma.

Answer 2

Si sus 'servicios' orquestan la lógica de negocio utilizando una serie de objetos de dominio, es muy probable la aplicación de la Facade Pattern - así que quizás se puede nombrar con este sufijo, por ejemplo OrderManagementFacade

Answer 3

Desde su descripción, suena al igual que las clases WCF en realidad están implementando un servicio host. Normalmente llamo tales clases con un sufijo de "ServiceHost". Los separa muy bien de las clases de servicio reales.

Así, por ejemplo, usted tendría su lógica de negocio en una clase llamada "a Cliente" y la clase WCF correspondiente sería llamado "CustomerServiceHost".