Aplicaciones WCF/Cliente: ¿a dónde debe ir la lógica comercial?

Question

Estamos creando un servicio web WCF usando WSSF. La idea es que expondrá nuestra base de datos principal a través del servicio y nos permitirá construir varias aplicaciones y sitios web sobre el servicio. Por el momento estoy construyendo una aplicación cliente simple que descargará algunos datos de este servicio, manipúlalo y luego entrégalo al usuario como un archivo CSV de informe.

Ahora la pregunta es ¿dónde debería ubicarse la lógica de negocios (que manipula los datos)? Pensé que lo pondría dentro del servicio. Ya tengo una capa de negocios con objetos simples que mapean casi uno a uno con la base de datos (cliente, orden, etc.). Pensé que haría algunos objetos de "nivel superior" para manipular los datos. Por ejemplo, al usar el cliente, el pedido y otros objetos y producir un informe, etc., pensé que el mejor lugar para esto sería en la capa de negocios para el servicio. De esa manera podríamos reutilizar esta lógica para varias aplicaciones diferentes si es necesario.

Desafortunadamente mi jefe no está de acuerdo. Él quiere una "separación de preocupaciones" y dijo que el lugar correcto para esta lógica sería en una capa empresarial dentro de la aplicación cliente en lugar de en el servicio. Supongo que esto podría ser más simple, pero me gustaría utilizar mi poderoso modelo de objetos dentro de la capa de negocios de servicios para escribir este código. Los objetos expuestos por el servicio no son objetos "reales" y en realidad son estructuras de datos ligeras sin la potencia del modelo de objetos completo que existe dentro de la capa de negocios de servicios.

¿Qué piensan? Muchas gracias por la ayuda.

Saludos Marcos

Answer 1

Creo que lo que es "correcto" depende de su arquitectura de aplicaciones. Ciertamente hay valor en la separación de las preocupaciones. Parece que su jefe considera que el modelo actual es utilizar el servidor como una capa de acceso a datos que mapea la base de datos a objetos comerciales y que la lógica de negocios debe implementarse en el cliente.

Aún puede tener una separación de preocupaciones si la lógica de negocio se implementa en el cliente o el servidor. No es donde hace el procesamiento lo que cuenta, sino cuán limpiamente ha diseñado las interfaces entre los niveles de la aplicación.

Puede ser útil saber más sobre el cliente. ¿Estás lidiando con un navegador/cliente de Javascript? Si es así, mantendría todo el procesamiento posible en el servidor y enviaría los datos al cliente más o menos en la forma que desea que se muestren.

Si es un cliente C#, entonces tiene mucho más poder para trabajar en ese extremo. Probablemente pueda reconstituir las respuestas del servicio WCF en las mismas clases de objetos comerciales que estaba utilizando en el lado del servidor y obtener el mismo poder que tenía en el servidor. (Simplemente comparta las clases de objetos comerciales entre las dos soluciones.)

Answer 2

No existe una regla rígida para esto, pero en este caso diría que su jefe está más equivocado que usted :) Todos tendrán un poco diferente opine sobre esto, y puede haber una serie de razones por las que su lógica comercial se ubica en lugares distintos a la capa de negocios, pero rara vez hay una razón para ponerlo en la aplicación del cliente; podría argumentar que cuando está en el cliente aplicación, entonces es una UI o regla de presentación en lugar de una regla comercial.

Si los servicios web van a ser utilizados por una serie de aplicaciones, entonces tanto como sea posible, usted quiere la lógica de negocios en el lado del servicio web. En realidad, tendría una capa de servicio web muy delgada, lo único que hace es aceptar la llamada y luego pasar la ejecución a la capa empresarial real. También tendría la asignación entre los datos de la base de datos y las entidades de datos empresariales en la capa de la base de datos, no en la capa empresarial.

Answer 3

Mi voto sería clara:

• poner la mayor de las comprobaciones de integridad de los datos en la base de datos
• poner cualquier otro control de lógica de negocios en una capa de lógica de negocio en el lado del servidor del servicio
• poner sólo comprueba simples como "campo requerido", etc., en la capa de cliente, de manera óptima se determina automáticamente a partir del modelo de base de datos o su modelo de negocio

¿Por qué base de datos?
SQL en cualquier forma o forma tiene algunas capacidades de verificación muy básicas y muy poderosas - asegúrese de que las cosas son únicas, asegúrese de que la integridad relacional entre las tablas es un dado y así sucesivamente - USE IT! Si realiza estos controles en la base de datos, no importa cómo se conecte finalmente su usuario a sus datos (escenario de horror: los gerentes pueden conectarse directamente a sus tablas con Excel para hacer algún trabajo de Inteligencia Comercial ...), cheques estarán en su lugar y serán aplicados. La aplicación de la integridad de los datos es el requisito más importante en cualquier sistema.

¿Por qué lógica de negocios en el servidor?
La misma razón que los otros contestadores han mencionado: centralización. No desea tener la lógica comercial y sus cheques solo en el cliente. ¿Qué ocurre si algún otro departamento de su empresa o un consultor externo externo comienza a usar su servicio repentinamente, pero no se han implementado todos los controles de validación y de negocios, ya que no los conocen? No es una buena cosa ......

Lógica en el cliente
Sí, por supuesto - también quiere poner algunos controles sencillos en el cliente, sobre todo si se trata de una aplicación web. Cosas como "este campo es obligatorio" o "longitud máxima para este campo", etc. deben aplicarse tan pronto como sea posible. Idealmente, esto será recogido automáticamente por los clientes desde la capa de base de datos/servicio. Los controles de servidor de ASP.NET tienen validación de cliente que se puede activar automáticamente, los Servicios de Silverlight RIA pueden recoger la restricción de datos en su modelo de datos back-end y transportarlos a la capa de cliente.