Separar la lógica comercial dependiente de las referencias web fuera de la capa de presentación

Question

Tengo una aplicación web con una capa de presentación y una capa de negocios como proyectos individuales. Uno es una aplicación web y la otra es una biblioteca de clase. He agregado una referencia web a la aplicación web para usar un servicio web. No tengo problemas para usar la API de servicio, pero me estoy encontrando agregando mucha lógica de tipo de comercio en mi capa de presentación para utilizar esta API. Me encantaría que pudiera cambiar parte de mi código de capa comercial para trabajar con el servicio web, pero la configuración de tales suena como una gran circular no. De todos modos, me encantaría que mis objetos puedan seguir haciendo lo que están haciendo, pero que también funcione con un servicio web, pero tengo que crear una clase de ayudante/administrador en mi capa de presentación para trabajar con la web -Servicio. Esto me hace requerir cambios en el código en todas partes donde estaba realizando las acciones en los objetos a los que quería agregar con el servicio. ¿Cuál es la forma correcta de atacar este problema?

Ni siquiera estoy seguro de que haya una pregunta legítima en cualquier lugar en todas esas divagaciones, pero si alguien pudiera ofrecer alguna palabra útil, agradecería mucho.

¡¡Gracias!!

Answer 1

La forma en que me he acercado a esto es crear algo a este sentido:

• Capa de acceso a datos
• Capa de lógica de negocios

• Capa de servicio (desprovista de cualquier lógica comercial, solo una interfaz)

  ---

• Capa de acceso de servicio (desprovisto de cualquier lógica de negocio o lógica de presentación)

• Capa de presentación (MVC, lógica de presentación, etc.)

Su capa de servicio está desprovista de lógica de negocios ahora se puede cambiar sin afectar la lógica de su negocio. La capa de acceso de su servicio en el lado del cliente también lo protege de los cambios en la interfaz de servicio.

Answer 2

Si su capa de servicio expone solo métodos similares a servicio (como quizás los métodos CRUD simples como SaveInvoice (factura)), entonces en la mayoría de los casos debería estar bien. Sin embargo, podríamos usar algún código de su lado.

Realmente hay muchas formas de construir capas de servicio, estatales, no estado, etc., etc., así que intente explicar qué repetición obtiene en su presentación.

Answer 3

¿Quizás debería hacer que su servicio encapsule la lógica comercial también? De esa manera, su capa de presentación solo accedería al servicio: el servicio accedería a la capa de lógica de negocios.