Validación y en la capa de servicio o Business Objects?

Question

Martin Fowler suggests usando una capa de servicio como un límite entre el modelo de dominio y y "Cargadores de datos". Sin embargo, Rockford Lhotka sugiere construir validación en el objeto comercial en sí mismo y esto es exactamente lo que hace CSLA.NET.

Los beneficios de la abstracción de esto en una capa de servicio es, obviamente, que su capa de servicios puede coordinar la actividad/operación a través de múltiples objetos de negocio. Pero, ¿cuáles son las otras ventajas y desventajas de utilizar una capa de servicio directamente utilizando objetos comerciales para la lógica y la validación comercial?

Answer 1

Definitivamente estoy en el campo de Rocky Lhotka. Creo que sus objetos de negocio deberían ser muy fáciles de "portar" entre las aplicaciones y las capas de la interfaz de usuario. Agregar una "capa de servicio" adicional muy probablemente agregará una dependencia con sus objetos y por lo tanto los hará menos "portátiles".

Si escribe su infraestructura de objeto empresarial correctamente, sus objetos de negocio debe ser capaz de manejar la validación correctamente entre varios objetos de negocio. CSLA.NET hace esto correctamente al tener relaciones padre/hijo así como el concepto de validación de propiedad dependiente.

Answer 2

no estoy seguro de si se ha dado cuenta de esto.

La sugerencia de Martin Fowler en el PEAA es la capa de servicio una API entre la UI (o los clientes) y las capas de Dominio/Datos. expondrá cualquier funcionalidad que pueda ser consumida por un cliente.

Si nos fijamos en el modelo de dominio (Here)

Un modelo de objeto del dominio que incorpora tanto el comportamiento y datos.

El nivel de dominio contendrá estos objetos, que tendrán las acciones/validación (comportamiento) y el estado (datos)

Estos objetos pueden ser reutilizados en otras aplicaciones, esto también dependerá de su diseño. la capa de dominio no debe depender de la capa de servicio

Por lo tanto, teniendo en cuenta que los objetos del Dominio tienen un comportamiento (esto incluye validación) y datos. la capa de Servicio es lo que quiere que su aplicación exponga (para funcionar). IE agrega un cliente, o cuenta, calcualte las facturas para el final del mes.

Tenga una mirada en el diseño de architure aguda (http://www.sharparchitecture.net/)

Este es mi entendimiento de este meterial.

HTH

huesos

Answer 3

Estoy en busca de un modelo de dominio más flexible donde hay una separación de datos y el comportamiento, pero no creo que la capa de servicio es la capa más apropiado para el comportamiento . En cambio, tal vez, uno podría tomar un enfoque simple de Capa Lógica Empresarial donde los objetos de la Entidad comercial solo exponen datos y los objetos del Proceso empresarial solo exponen el comportamiento, y entre esos comportamientos se encuentran los métodos de validación.

Uno de los beneficios, dependiendo de cuán flojo es el acoplamiento de procesos de negocios, puede aplicar la validación a una gama más amplia de covariantes y posiblemente incluso a tipos invariables.Considere por un momento validar los campos "Nombre" y "Apellido", y además considere que estos campos pueden, en cualquier sistema grande, existir en media docena o más entidades diferentes. Separar el proceso de los datos garantizaría que pueda implementar sus procesos de validación una vez y aplicarlos sobre muchos objetos que proporcionan los mismos datos.

He notado que el ideal de que el Modelo de Dominio 'debería' estar compuesto de Objetos de Dominio que son una fusión de Datos y Comportamiento es un concepto de Fowler/Evans, circa 2000-2002 (poco después de una migración rápida hacia sistemas de información distribuidos en lugar de aplicaciones en 2 capas.)

Pensamientos?