Este artículo proviene de un motor de traducción automática.

Cutting Edge

Ventajas y desventajas de datos de transferencia de objetos

Dino Esposito

Contenido

Modelos de procedimientos para BLL
Con objeto modelos para BLL
La capa de servicio
Introducción a objetos de transferencia de datos
Otras ventajas de DTOs
Inconvenientes de DTOs
Hacer referencia directamente a entidades
La forma de medio
Enfoque mixto

Casi cada programador y arquitecto podrían acordar de los siguientes, aunque relativamente sueltos, definición de la capa de lógica empresarial (BLL) de una aplicación de software: el BLL es la parte de la aplicación de software relacionado con el rendimiento de las tareas relacionadas con empresariales.Código de la capa BLL opera sobre datos que intenta entidades de modelo en el dominio del problema, facturas, clientes, pedidos y similares.Operaciones en el intento BLL para modelar procesos empresariales.

De forma subyacente de esta definición ampliamente aceptada reside un número de detalles de clave que quedan indefinido y no especificado.Patrones de diseño existen para ayudar a los arquitectos y diseñadores código transformar las definiciones de sueltas en planos.En general, patrones de diseño BLL tienen un enfoque ligeramente diferente.Se modelo operaciones y los datos y suele servir como el punto de partida para diseñar la capa BLL.

En este artículo, tras un breve actualizador en patrones basados en el objeto y procedimientos para organizar el BLL, me centraré en el uno lado del problema, objetos de transferencia de datos, que si no eficazmente tratado en el nivel de arquitectura, puede tener un profundo impacto en el desarrollo del proyecto.

Modelos de procedimientos para BLL

En cuanto al diseño de la capa BLL, puede iniciar desde los casos de uso que han surgido durante la fase de análisis.Normalmente, al final de un método para cada requiere interacción entre el usuario y el sistema de codificación.Una transacción lógica que incluye todos los formularios de cada interacción pasos vencimiento, de recopilación de entrada para realizar la tarea y de acceso de la base de datos al actualizar la interfaz de usuario.Este enfoque se conoce como el modelo de secuencias de comandos de transacción (TS).

En Terminal, se centran en las acciones necesarias y realmente no generar un modelo conceptual del dominio como el Centro de la aplicación gravitacional.

Para mover datos alrededor, puede utilizar los objetos de contenedor que pueden adaptarse.En el espacio de Microsoft. NET, esto significa principalmente mediante contenedores de datos ADO.NET como DataSet y DataTable.Estos objetos son un tipo de objeto super-array, con algunas de la búsqueda, indización y las capacidades de filtrado.Además, DataSet y DataTable se pueden serializar fácilmente a través de niveles y incluso se almacena localmente en habilitar escenarios sin conexión.

El modelo de TS no impone un modelo concreto para la representación de datos (y no impide cualquier cualquiera).Normalmente, las operaciones se agrupan como métodos estáticos en uno o más clases de punto de entrada.Como alternativa, las operaciones pueden implementarse como comandos en un enfoque de modelo de comando.Organización del acceso a datos se deja al desarrollador y generalmente se produce en fragmentos de código de ADO.NET.

El modelo de TS es bastante fácil de configurar; al mismo tiempo obviamente no escala que bien a medida que crece la complejidad de la aplicación.En el espacio de .NET otro patrón ha obtenido la amplia aceptación en los años: el patrón de módulo de la tabla.En pocas palabras, el modelo de módulo de la tabla sugiere una visión centrada en la base de datos de la capa BLL.Es necesario crear un componente empresarial para cada tabla de base de datos.Conocido como la clase de módulo de la tabla, el componente comercial empaqueta los datos y el comportamiento juntos.

En el módulo de la tabla modelo, la capa BLL se divide en un conjunto de componentes general, cada uno representa una tabla de base de datos completa.Está estrictamente orientado a la tabla, el modelo de módulo de la tabla presta a utilizando las estructuras de datos del conjunto de registros como para pasar datos alrededor.Contenedores de datos ADO.NET o, mejor aún, personalizada y con la versión de contenedores ADO.NET son la opción natural.

Como surge la necesidad de una vista más conceptual de dominio del problema, los patrones BLL que han trabajado durante años en el espacio de .NET que evolucionar algunos más.Los arquitectos tienden a generar un modelo de entidad y la relación que representa el dominio del problema y examine las tecnologías como LINQ para SQL y Entity Framework como herramientas concretas para ayudar a.

Con objeto modelos para BLL

El modelo de módulo de la tabla se basa en objetos, pero no es realmente un modelo basado en objetos para modelar la lógica empresarial.Tiene objetos, pero son objetos que representan las tablas, no los objetos que representa el dominio del problema.

En un diseño orientado a objetos, la lógica empresarial identifica las entidades y expresa todas las interacciones permitidas y necesarias entre entidades.Al final, la aplicación se ve como un conjunto de objetos interrelacionados y interoperating.El conjunto de objetos de asignación a entidades, además de algunos objetos especiales, realizar cálculos formulario el modelo de dominio.(En Entity Framework, expresa el modelo de dominio mediante Entity Data Model [EDM]).

Hay varios niveles de complejidad en un modelo de dominio que sugieran distintos patrones, normalmente el modelo de registro Directory o el modelo del modelo de dominio.Una buena medida de esta complejidad es las diferencias entre el modelo de entidad que tiene en mente y el modelo relacional datos que va a crear para almacenar datos.Un modelo de dominio simple es uno en el que las entidades asignan estrechamente a tablas en el modelo de datos.Un modelo simple por lo que no requiere la asignación a cargar y guardar objetos de dominio en una base de datos relacional.

El modelo de registro Active es una elección ideal cuando necesite un modelo de dominio simple; en caso contrario, cuando es preferible idear entidades y relaciones independientemente de ninguna noción de base de datos, el modelo de modelo de dominio es la forma.

El modelo de registro Active es similar a lo que se obtiene de un modelo de objetos LINQ para SQL (y el modelo de defaultgenerated con el Diseñador de entidades de Entity Framework versión 1.0).Iniciar desde una base de datos existente, crear objetos que asignan una fila de una tabla de base de datos.El objeto tendrá una propiedad para cada columna de tabla del mismo tipo y con las mismas restricciones.La formulación del modelo de registro Active original, se recomienda que cada objeto pasa a responsable de su propia persistencia.Esto significa que cada clase de entidad debe incluir métodos, como guardar y cargar.Ni LINQ para SQL Entity Framework hace aunque, como ambos persistencia de delegado a una infraestructura O/RM integrada que actúa como capa de acceso de datos reales, como se muestra en la figura 1 .

Figura 1 arquitectura por capas de A – PatternUsed el modelo de dominio para la capa BLL

La capa de servicio

En la figura 1 , verá una sección lógica de la capa BLL denominan el "capa de servicio" sentado entre la capa de presentación y la capa que se ocupa de persistencia.En pocas palabras, la capa de servicio define una interfaz para la capa de presentación desencadenar acciones predefinidas del sistema.La capa de servicio desacopla la presentación y lógica empresarial y representa la fachada para la lógica de presentación llamar a la capa BLL.La capa de servicio realiza su propio trabajo regardless of cómo está organizada internamente la lógica empresarial.

Como desarrollador de .NET es bastante familiarizado con los controladores de eventos en formularios Web o de Windows.El método Button1_Click canónico pertenece a la capa de presentación y expresa el comportamiento del sistema después el usuario ha hecho clic en un botón determinado.Comportamiento del sistema; más exactamente, el caso de uso que está implementando, pueden requerir alguna interacción con componentes BLL.Normalmente, deberá crear una instancia del componente BLL y, a continuación, secuencias de comandos.El código necesario para el componente de secuencia de comandos puede ser tan sencillo como llamar al constructor y quizás un método.Con más frecuencia, sin embargo, dicho código es bastante enriquecido con ramas y necesite llamar a varios objetos o esperar una respuesta.La mayoría de desarrolladores hacer referencia a este código como lógica de aplicación.Por lo tanto, la capa de servicio es el lugar en la capa BLL dónde almacenar la lógica de aplicación, manteniendo distintos e independientes de la lógica del dominio.La lógica de dominio es cualquier lógica plegado en las clases que representan entidades de dominio.

En la figura 1 , los bloques de modelo de capa y el dominio de servicio son distintas partes de la capa BLL, aunque es probable que pertenezcan a distintos ensamblados.La capa de servicio conoce el modelo de dominio y se hace referencia al ensamblado correspondiente.El ensamblado de capa de servicio, en su lugar, se hace referencia en la capa de presentación y representa el único punto de contacto entre cualquier capa de presentación (ya sea Windows, Web, Silverlight o móvil) y la capa BLL.figura 2 muestra el gráfico de referencias que conectan los actores distintos.La capa de servicio es una especie de mediador entre la capa de presentación y el resto de la capa BLL.Como tal, mantiene separados perfectamente pero correspondencia imprecisa para que sean perfectamente capaces de comunicarse.En la figura 2 , la capa de presentación no contiene cualquier referencia al ensamblado de modelo de dominio.Esto es una elección diseño clave para las soluciones más capas.

Figura 2 gráfico de referencias entre actores de participante

Introducción a objetos de transferencia de datos

Cuando haya una visión basada en el dominio de la aplicación, no ayuda pero busque serio en datos de objetos de transferencia.Ninguna solución de varios niveles basada en LINQ to SQL o Entity Framework es inmune a este problema de diseño.¿La pregunta es cómo podría mover datos a y desde la capa de presentación?¿Dicho de otra forma, debe la capa de presentación contenga una referencia al ensamblado de modelo de dominio?(En un escenario de Entity Framework, el ensamblado de modelo de dominio es simplemente la DLL creado fuera del archivo EDMX.)

Idealmente, el diseño debe parecerse a la figura 3 , donde en que objetos made-to-measure se utilizan para pasar datos de la capa de presentación a la capa de servicio y hacer de seguridad.Estos objetos contenedor ad hoc tomar el nombre de objetos de transferencia de datos (DTOs).

Figura 3 andService nivel de comunicación entre el nivel de presentación

Un DTO es nada más que una clase de contenedor que expone propiedades pero no métodos.Un DTO es útil siempre que necesite valores de grupo en estructuras ad hoc para pasar datos alrededor.

Desde una perspectiva de diseño puro, DTOs son una solución realmente cercana a la perfección.DTOs ayuda a desacoplar aún más la presentación de la capa de servicio y el modelo de dominio.Cuando se utilizan DTOs, la capa de presentación y la capa de servicio comparten contratos de datos en lugar de clases.Un contrato de datos es esencialmente una representación neutral de los datos que interactúan los componentes de exchange.El contrato de datos describe los datos que recibe de un componente, pero no es una clase específica del sistema, como una entidad.Al final del día, un contrato de datos es una clase, pero es más parecida a una clase auxiliar creada específicamente para un método de servicio determinado.

Una capa de DTOs aísla el modelo de dominio de la presentación, lo que de acoplamiento flexible y transferencia de datos optimizado.

Otras ventajas de DTOs

La adopción de contratos de datos agrega una gran cantidad de flexibilidad a la capa de servicio y, posteriormente, en el diseño de toda la aplicación.Por ejemplo, si se usan DTOs, un cambio en los requisitos que fuerza un movimiento a una cantidad diferente de datos no tiene ningún impacto en la capa de servicio o incluso el dominio.Puede modificar la clase DTO implicada agregando una nueva propiedad, pero deja intacta la interfaz general de la capa de servicio.

Debe tenerse en cuenta que un cambio en la presentación probablemente significa un cambio en uno de los casos de uso y, por lo tanto, en la lógica de aplicación.Debido a la capa de servicio procesa la lógica de aplicación, en este contexto un cambio en la interfaz de nivel de servicio es todavía aceptable.Sin embargo, en mi experiencia, las modificaciones repetidas de la interfaz de nivel de servicio pueden conducir a la conclusión errónea que cambia en los objetos de dominio, las entidades, puede ahorrar más modificaciones en la capa de servicio.Esto no suceda en equipos well-disciplined o cuando los desarrolladores tienen un conocimiento profundo de la separación de funciones que existe entre el modelo de dominio, la capa de servicio y DTOs.

Como muestra la figura 4 , cuando se emplean DTOs, también necesita una capa de adaptador DTO para adaptarse a uno o más objetos de entidad para una interfaz diferente según el caso de uso.Al hacerlo, realmente implemente el modelo "Adaptador", uno de los patrones de diseño clásico y más populares.El modelo de adaptador convierte esencialmente la interfaz de una clase en otra interfaz que espera un cliente.

Figura 4 adaptadores DTO en la capa BLL

Con referencia aFigura 4, la capa de adaptador es responsable de leer una instancia de la clase OperationRequestDTO entrante y para crear y llenar las instancias nuevas de OperationResponseDTO.

Cuando los requisitos cambian y forzar los cambios en una capa de servicio basado en DTO, todo que necesita hacer es actualización de los datos públicos contrato de la DTO y ajustar el adaptador DTO correspondiente.

Las ventajas de DTOs desacoplamiento no termina aquí.Además, para mantenerse Afortunadamente cambios en la presentación, puede introducir los cambios a las entidades en el modelo de dominio sin afectar a los clientes es posible que tenga.

Cualquier modelo de dominio realista contiene relaciones, como pedidos de clientes y pedidos a clientes que forman un vínculo doble entre entidades Customer y Order.Con DTOs, también evitar el problema de administrar las referencias circulares durante la serialización de objetos de entidad.DTOs pueden crearse para ejecutar una secuencia sin formato de valores que, si es necesario, serializar muy bien los límites.(Volverá a este punto en un momento.)

Inconvenientes de DTOs

¿Desde una perspectiva de diseño puro, DTOs son una ventaja real, pero está este punto teórico confirmado por la práctica, demasiado?Como en muchos puntos abierto de arquitectura, la respuesta es, que depende.

Tener cientos de entidades en el modelo de dominio definitivamente es una buena razón para enfocar alternativas a un enfoque basado en DTO puro.En proyectos grandes con muchas entidades, DTOs agregar un nivel notables de complejidad (adicional) y el trabajo por hacer.En breve, puro, 100 % DTO solución suele ser sólo una solución dolorosa del 100 por ciento.

Aunque normalmente se mide la complejidad que agrega a una solución por DTOs con la cardinalidad del modelo de dominio, el número real de DTOs necesarios puede ser que más confiable determinan mirando los casos de uso y la implementación de la capa de servicio.Una fórmula para estimar cuántos DTOs necesita buena es buscar en el número de métodos de la capa de servicio.El número real puede ser más pequeños si puede reutilizar algunas DTOs en varias llamadas de capa de servicio o posterior si sus DTOs grupo algunos datos utilizando tipos complejos.

En resumen, el único argumento frente DTOs es el trabajo adicional necesario para escribir y administrar el número de clases DTO resultantes.No es, sin embargo, se importa un simple de pereza del programador.En grandes proyectos desacoplamiento presentación desde la capa de servicio costos cientos de nuevas clases.

Se debe también tener en cuenta que un DTO no es simplemente una ligera copia de cada entidad que puede tener.Suponga que dos casos de uso distintos necesario devolver una colección de pedidos, por ejemplo, GetOrdersByCountry y GetOrdersByCustomer.Muy probablemente, la información para poner en "pedido" es diferente.Probablemente necesitará más (o menos) detalles en GetOrdersByCustomer que en GetOrdersByCountry.Esto significa que DTOs distintos son necesarios.Por este motivo, cientos de entidades ciertamente son una medida de complejidad rápida, pero el número real de DTOs puede determinarse sólo mediante mirando los casos de uso.

Si DTOs no siempre están óptimas, ¿cuál sería un enfoque alternativo viable?

La única alternativa al uso DTOs es hacer referencia el ensamblado, modelo de dominio desde dentro de la capa de presentación.Sin embargo, en este modo establece un estrecho acoplamiento entre capas.Y capas de acoplamiento ajustado pueden ser un problema incluso peor.

Hacer referencia directamente a entidades

Una condición primera, no forma obvia para habilitar el vínculo de entidades directamente desde la capa de presentación es que es aceptable para la capa de presentación recibir datos en el formato de objetos de entidad.A veces la presentación necesita datos con formato de una manera determinada.Una capa de adaptador DTO existe a sólo datos de mensajes según el cliente.Si no utiliza DTOs sin embargo, la carga de formato de datos correctamente debe moverse hasta la capa de presentación.De hecho, el lugar incorrecto en el que los datos de formato para propósitos de la interfaz de usuario es el modelo del dominio.

De forma realista, puede hacerlo sin DTOs sólo si la capa de presentación y la capa de servicio son coincidir en el mismo proceso.En este caso, puede hacer fácilmente referencia el ensamblado, entidad desde dentro de ambas capas sin tratar thorny problemas como la serialización de interacción remota y los datos.¿Esta consideración se lleva a otra buena pregunta: que se debe ajustar la capa de servicio?

Si el cliente es una página Web, la capa de servicio es preferiblemente local para el servidor Web que aloja la página.En las aplicaciones ASP.NET, la capa de presentación está todo en las clases de código subyacente y vive en paralelo con la capa de servicio en el mismo AppDomain.En un escenario, cada comunicación entre la capa de presentación y la capa de servicio tiene lugar en proceso y objetos pueden compartirse con no más preocupaciones.Las aplicaciones ASP.NET son un buen escenario donde puede probar una solución que no utilice el nivel adicional de DTOs.

Technology-Wise, puede implementar la capa de servicio a través de objetos de .NET sin formato o a través de servicios de Windows Communication Foundation (WCF) local.Si la aplicación es correcta, puede aumentar fácilmente la escalabilidad cambiando la capa de servicio a un servidor de aplicación independiente.

Si el cliente es una aplicación de escritorio, a continuación, la capa de servicio es normalmente implementan en un nivel diferente y acceso remoto desde el cliente.Mientras el cliente y el servidor remoto comparten la misma plataforma. NET, puede utilizar remoting técnicas (o, mejor, los servicios de WCF) para implementar la comunicación y seguir utilizando objetos de entidad nativo en ambos extremos.La infraestructura WCF se encargarse de calcular referencias de datos a través de niveles y bomba en copias de entidades nativas.Además, en este caso puede organizar una arquitectura que no utilice DTOs.Cosas cambiar considerablemente si las plataformas de cliente y servidor son incompatibles.En este caso, no tiene posibilidades para vincular los objetos nativos y invocar desde el cliente; posteriormente, se encuentra en un escenario puro orientadas al servicio y uso DTOs es la única posibilidad.

La forma de medio

DTOs son el asunto de una opción de diseño importante que afecta a la implementación de cualquier comunicación entre la presentación y el servidor del sistema.

Si emplea DTOs, mantener el sistema escasamente acoplado y abra hacia una variedad de clientes.DTOs son la elección ideal si puede permitirse.DTOs agregar un significativo programación sobrecarga para cualquier sistema del mundo real.Esto no significa que no debe utilizarse DTOs, pero conducir a una proliferación de las clases que realmente puede prefigure una pesadilla de mantenimiento en proyectos con unos pocos cientos de entidad de objetos y aún más casos de uso.

Si se encuentra en el mismo tiempo un proveedor y consumidor de la capa de servicio, y si tiene control total sobre la presentación, puede haber beneficios hacer referencia al ensamblado de modelo de entidad de la presentación.De esta manera, todos los métodos en la capa de servicio se permiten utilizar clases de entidad como los contratos de datos de sus firmas.El impacto en diseño y codificación es claramente bastante más suave.

Si desea utilizar DTOs o no es no un punto de fácil generalize.Para ser eficaces, la decisión final siempre se debe realizar examina los detalles del proyecto.Al final, un enfoque mixto sea lo que realizará la mayor parte del tiempo.Personalmente, Tiendo a utilizan entidades como puedo.Esto sucede, no porque yo contra pureza y diseño limpio, pero para una cuestión más sencilla de pragmatism.Con un modelo de entidad cuentas para las entidades sólo 10 y unos pocos casos de uso, utilizando DTOs todo a través no plantean cualquier problema significativo.Y obtener ordenado diseño mínimo acoplamiento.Sin embargo, con cientos de entidades y uso casos, el número real de clases para escribir, mantienen y prueba ominously aproxima el orden de miles.Cualquier reducción posible de complejidad que cumple los requisitos es mayor que Bienvenido.

Como arquitecto, sin embargo, siempre debe en la alerta para reconocer los signos que indica que la distancia entre el modelo de entidades y la presentación lo que se espera es significativo o imposible cubrir.En este caso, debe tomar la ruta más segura (y limpieza) de DTOs.

Enfoque mixto

Las aplicaciones de hoy en capas reservan una sección de la capa BLL a la capa de servicio.El nivel de servicio (también denominado la capa de aplicación) contiene la lógica de aplicación; es decir, la reglas de negocio y procedimientos que son específicos para la aplicación pero no para el dominio.Un sistema con varios extremos frontal expondrá una única pieza de lógica de dominio a través de clases de entidad, pero a continuación, en la que cada cliente tendrá una capa de negocio adicionales específica de los casos de uso es compatible con.Esto es lo que se conoce como la capa de servicio (o aplicación).

Se desencadena desde la interfaz de usuario, la lógica de aplicación scripts las entidades y servicios en la lógica empresarial.En la capa de servicio implementa los casos de uso y exponer cada secuencia de pasos a través de un método general para la presentación llamar a.

En el diseño de la capa de servicio, quizás desee aplicar unos procedimientos recomendados, adoptar servicio orientación y compartir contratos de datos en lugar de clases de entidad.Entra en aunque este enfoque es ideal en teoría, a menudo conflicto con el mundo real, como termina agregar demasiada sobrecarga en proyectos con cientos de entidades y casos de uso.

Resulta que un enfoque mixto que utiliza datos de contratos sólo cuando utilizando las clases no es posible, suele ser la solución más aceptable.Pero como un arquitecto debe no hacer esta decisión ligera.Se permite infringir las reglas de un buen diseño, siempre que sepa lo que está haciendo.

Envíe sus preguntas y comentarios para Dino aCutting@Microsoft.com.

Dino Esposito es un arquitecto en IDesign y coautor de Microsoft .NET: Architecting Applications for the Enterprise (Microsoft Press, 2008).En función de Italia, Dino es ponente habitual en eventos del sector en todo el mundo.Puede unirse a su blog enweblogs.ASP.net/.