Arquitectura aplicaciones .net

Arquitectura de aplicaciones .NET: Diseño de
aplicaciones y servicios
Patterns & Practices
Microsoft Corporation
Diciembre de 2002

Tabla de Contenido
Guía Básica ............................................ vii
Contenido del capítulo ix
Profesionales a los que se destina la guía ix
Contenido de la guía x
Información básica xi
Colaboradores xi
Comentarios y soporte xii
Capítulo1: Introducción .............................................. 1
Contenido del capítulo 3
Objetivos del diseño de aplicaciones distribuidas 4
Servicios e integración de servicios 4
Componentes y niveles en aplicaciones y servicios 7
Escenario de ejemplo 9
Capítulo 2: Diseño de los componentes de una aplicación o
servicios ............................................ 11
Tipos de componentes 11
Recomendaciones generales relativas al diseño de aplicaciones y
servicios 14
Diseño de capas de presentación 15
Diseño de componentes de interfaz de usuario 16
Diseño de componentes de proceso de usuario 29
Diseño de capas empresariales 40
Componentes y flujos de trabajo empresariales 41
Diseño de una interfaz de servicios 51
Representación de datos y pasarlos a través de niveles 54
Recomendaciones relativas al diseño de entidades empresariales 57
Diseño de capas de datos 58
Almacenes de datos 60
Componentes lógicos de acceso a datos 60
Diseño de componentes de ayuda de acceso a datos 68
Integración con servicios 69
Capítulo 3: Directivas de seguridad, administración operativa y
comunicaciones ............................................ 73
Diseño de la directiva de seguridad 76

Principios generales sobre seguridad 76
Autenticación 77
Autorización 83
Comunicación segura 92
Administración de perfiles 95
Auditoría 95
Diseño de la directiva de administración operativa 96
Administración de excepciones 97
Supervisión 101
Configuración 103
Metadatos 105
Ubicación de servicios 108
Diseño de la directiva de comunicaciones 110
Elección del modelo de comunicación correcto 110
Sincronización 116
Recomendaciones para comunicaciones 120
Formato, esquema y protocolo de comunicaciones 121
Un vistazo al futuro 122
Capítulo 4: Implementación física y requerimientos operativos
.......................................... 123
Implementación de los componentes de la aplicación 125
Entornos físicos de implementación 125
Planeamiento de la ubicación física de los componentes de la
aplicación 130
Límites de distribución entre componentes 134
Partición de la aplicación o el servicio en ensamblados 137
Empaquetado y distribución de los componentes de la aplicación139
Patrones comunes de implementación 140
Escenarios de interfaz de usuario basados en Web 141
Escenarios de interfaz de usuario de cliente enriquecido 143
Escenarios de integración de servicios 145
Entornos de producción, prueba y ensayo 149
Requerimientos operativos 150
Escalabilidad 150
Disponibilidad 152
Capacidad de mantenimiento 153
Seguridad 154
Facilidad de uso 155
Rendimiento 155
Apéndices y Glosario .......................................... 157
Apéndice 1: Mapa de productos 159
Apéndice 2: Glosario 161
Ensamblado 161

Transacción atómica 161
Conmutatividad 162
Componente 162
Contrato 162
Conversación 162
CRUD 162
Zona desmilitarizada (DMZ) 162
Enrutamiento dinámico de datos (DDR) 162
Emisario 163
Feudo 163
Servidor de seguridad 163
Idempotencia 163
Capa 163
Transacción de ejecución larga 163
Mensaje 163
Organización 164
Directiva 164
Servicio 164
Agente de servicios 164
Interfaz de servicios 164
Con estado 164
Sin estado 164
Confirmación en dos fases 164
Flujo de trabajo 164
Zona 165
Apéndice 3: Arquitecturas por capas 165

Guía Básica
Diciembre de 2002

Guía Básica
Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios ix
Resumen: en esta guía se proporcionan las instrucciones a nivel de diseño para la arquitectura y el
diseño de aplicaciones y servicios de .NET Framework, basados en Windows 2000 y en la versión 1.0
de .NET Framework. Se analizará la partición de la funcionalidad de las aplicaciones en componentes, se
describirán sus principales características de diseño, se explicará cómo se aplica la seguridad,
administración y comunicación a cada capa; asimismo, se proporciona información sobre el modo de
implementación de los componentes. Durante la localización de este artículo, la versión en español de
BizTalk 2002 no estaba disponible, por este motivo aparecen varias capturas de pantalla y opciones de
software en inglés. En estos casos, se ha agregado la opción de software en español entre paréntesis.
Contenido del capítulo
Profesionales a los que se destina la guía
Contenido de la guía
Información básica
Colaboradores
Comentarios y compatibilidad
Profesionales a los que se destina la guía
La guía está dirigida a arquitectos y responsables de desarrollo, o bien, para quien necesite:
• Determinar cómo se divide una aplicación en distintos componentes.
• Seleccionar las tecnologías que se utilizarán en una línea transaccional de servicio o aplicación
empresarial.
• Diseñar las directivas de administración y seguridad que se deben aplicar.
• Decidir el modo de implementación de la aplicación.
Esta guía se aplica a las aplicaciones transaccionales u OTLP que se ajusten a un diseño en capas y se
puedan distribuir en diversos niveles físicos con las siguientes tecnologías: ASP.NET, Servicios Web,
Enterprise Services (COM+), Remoting, ADO.NET y SQL Server. Algunos de los principios de diseño
incluidos en esta guía pueden ser útiles en escenarios similares.
El diseño de aplicaciones distribuidas no es una tarea sencilla. Es necesario tomar un gran número de
decisiones a nivel de arquitectura, diseño e implementación. Estas decisiones tendrán un impacto en las
"capacidades" de la aplicación (seguridad, escalabilidad, disponibilidad y mantenimiento, entre otras), así
como en la arquitectura, el diseño y la implementación de la infraestructura de destino. La guía le ayudará
a comprender las distintas opciones que se presentan a la hora de diseñar las capas de una aplicación
distribuida; estas opciones se presentan como un conjunto de capas de componentes que se podrán
utilizar para modelar la aplicación. En la figura 1 se muestran las capas de los componentes lógicos que
este documento utiliza para estructurar sus instrucciones. En el capítulo 2 se describe la mayor parte de
estas capas.

Guía Básica
x Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios
Figura 1.0. Capas de componentes de servicios y aplicaciones distribuidas creadas con .NET
Contenido de la guía
Capítulo 1: Introducción
Este capítulo describe el objetivo principal del diseño de aplicaciones distribuidas. Asimismo, se explica la
relación de los servicios y la integración de éstos con el desarrollo tradicional de aplicaciones, mostrando
un escenario comercial sencillo utilizado como tema para mostrar ejemplos en la guía.
Capítulo 2: Diseño de los componentes de una aplicación o servicio
En este capítulo se analizan todos los aspectos de una aplicación distribuida, comenzando por la interfaz
de usuario. También se identifican los distintos tipos de componentes o capas que se suelen utilizar en
aplicaciones eficaces. Se describen las principales decisiones que se deben tomar en relación con la
tecnología y el diseño, así como los principios básicos para el diseño de estos componentes.
Capítulo 3: Directivas de seguridad, administración operativa y comunicaciones
En este capítulo se analizan los diferentes aspectos, tales como la autorización y administración de
excepciones, que afectan al diseño de las capas de la aplicación, así como el modo en que las decisiones
de diseño se pueden aplicar a la misma. Asimismo, se describe la selección de los mecanismos de
comunicación.

Guía Básica
Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios xi
Capítulo 4: Implementación física y requisitos operativos
Este capítulo explica el modo de implementación de las capas de componentes lógicos en una
infraestructura compuesta por diversos niveles físicos. Se muestran patrones comunes de implementación
eficaces que se presentan cuando se combinan las capas de componentes lógicos, los niveles físicos y los
requisitos operativos.
Capítulo 5: Apéndices
Los apéndices incluyen un glosario, un mapa de productos y tecnologías de Microsoft que permiten
implementar o mejorar las capas de componentes de la aplicación, descritas en el capítulo 2, así como una
lista de nombres y patrones relacionados que la industria aplica a estas capas.
Información básica
Para sacar el máximo partido de la guía, debe tener experiencia en el uso de tecnologías y técnicas de
desarrollo .NET. Debe estar familiarizado con los temas generales de la arquitectura de aplicaciones
distribuidas y, si ya ha implementado soluciones de aplicaciones Web de .NET, debe conocer la propia
arquitectura de la aplicación y el patrón de implementación.
Colaboradores
Arquitecto de la solución y Administrador de programas: Edward A. Jezierski
Nuestro agradecimiento a los siguientes colaboradores, patrocinadores y revisores:
Keith Short, Mike Pizzo, Johannes Klein, Rodney Limprecht, Chris Anderson, Anders Hejlsberg, David
Treadwell, Jonathan Hawkins, Erik Olson, Brad Rhodes, Rob Howard, Ron Jacobs, John Shewchuck, Luca
Bolognese, David Schleifer, Riyaz Pishori, Pablo Castro, Brian Pepin, Mark Boulter, Shawn Burke, Michael
Platt, Maarten Mullender, Mike Burner, Dino Chiesa, John Montgomery, Richard Burte, Steve Kirk, Richard
Irving, Srinath Vasireddy, Steve Newbury, Sharon Bjeltich, Tom Devey, Kurt Schenk, Bryan Lamos, Paddy
Srinivasan, Yves Dolce, Rob Macdonald, Mark Phillips, Blair Shaw, Jeremy Rule, Paul Gomes, Dale Michalk,
Martin Petersen-Frey, Angela Crocker, Kenny Jones, Ilia Fortunov, Shantanu Sarkar, Rossen Blagoev, the
Think Tank, Bijan Javidi, Bob Jarvis, Aaron Margosis, Maurice Magnier, Doug Orange, Eugenio Pace, Carlos
Billy Reynoso, Anthony Menio, Karl Schulmeisters, Ingo Ramner, Bernard Chen (Sapient), Dimitris
Georgakopoulos (Sapient), Michael Monteiro (Sapient), Roger Sessions (ObjectWatch), Andrew Roubin,
Diego Gonzalez (Lagash), Adrie Geelhoed (CMG), Gerke Geurts (CMG), Sasha Siddhartha y Franco Ceruti
(VBNext).
Guías de arquitectura prescriptiva y equipo de contenido:
Redactores técnicos: Graeme Malcolm (Content Master Ltd) y Lin Joyner (Content Master Ltd).
Filiberto Selvas Patiño, Michael Kropp, Per Vonge Nielsen, Shaun Hayes, J.D. Meier, Rick Maguire, Philip
Teale, Ken Perilman, David Trowbridge, Mohammad Al-Sabt, Lars Laakes, Sharon Smith, Chris Sfanos,
Claudia Iebbiano (Wadeware) y el comité de revisión de la arquitectura de Satyam Computer Services Ltd.

Guía Básica
xii Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios
Comentarios y soporte
Si desea formular alguna pregunta sobre la guía o realizar algún comentario o sugerencia, envíe un
mensaje de correo electrónico a devfdbck@microsoft.com.
Puede ponerse en contacto con el grupo de noticias para realizar consultas a colegas, compañeros y
profesionales de soporte de Microsoft en un foro abierto en línea. Los demás usuarios también se
beneficiarán con sus preguntas y comentarios; nuestro equipo de desarrollo supervisa el grupo de noticias
periódicamente:
Grupo de noticias: Web-Based Reader
http://msdn.microsoft.com/newsgroups/loadframes.asp?icp=msdn&slcid=us&newsgroup=microsoft.public
.dotnet.distributed_apps (en inglés)
Grupo de noticias: NNTP Reader
news://msnews.microsoft.com/microsoft.public.dotnet.distributed_apps (en inglés)
El código de ejemplo y las instrucciones se proporcionan tal cual. Aunque este material ha sido sometido a
comprobaciones y se considera un conjunto sólido de procedimientos y recomendaciones, no se ofrece
soporte como con otros productos de Microsoft.
© 2003 Microsoft Corporation. Reservados todos los derechos. Condiciones de uso.

Capítulo1: Introducción
Diciembre de 2002

Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios 3
Resumen: en este capítulo se describe la arquitectura de alto nivel de una aplicación o servicio .NET
distribuido.
Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios proporciona instrucciones sobre el
nivel de arquitectura y diseño para arquitectos y desarrolladores de aplicaciones que necesitan generar
soluciones distribuidas con Microsoft® .NET Framework.
Debe leer esta guía si:
• Diseña arquitectura de alto nivel para aplicaciones o servicios.
• Recomienda tecnologías apropiadas para aspectos específicos de su aplicación o servicio.
• Toma decisiones de diseño que cumplen requisitos funcionales y no funcionales (operativos).
• Elige los mecanismos de comunicaciones adecuados para su aplicación o servicio.
Esta guía identifica las decisiones de diseño clave que necesita tomar durante las primeras fases del
desarrollo y proporciona instrucciones a nivel de diseño que le ayudarán a elegir entre distintas opciones
de diseño. Asimismo, le ayuda a desarrollar un diseño global mediante la presentación de una arquitectura
coherente construida con distintos tipos de componentes que le ayudarán a lograr un buen diseño y
beneficiarse de la plataforma Microsoft. Aunque esta guía no pretende proporcionar instrucciones a nivel
de implementación para cada aspecto de la aplicación, ofrece referencias a determinadas guías Microsoft
Patterns & Practices, artículos de MSDN y sitios de comunidad que debaten con detalle varios aspectos del
diseño de aplicaciones distribuidas. Puede considerar este documento como una guía básica de los
aspectos más importantes relativos al diseño de aplicaciones distribuidas con los que se encontrará al
utilizar la plataforma Microsoft.
Esta guía se centra en aplicaciones distribuidas y servicios Web que puede que sean necesarios para
proporcionar capacidades de integración para varios orígenes de datos y servicios, así como que requieran
una interfaz de usuario para uno o varios dispositivos.
El artículo asume que está familiarizado con el desarrollo de componentes .NET y los principios básicos del
diseño de aplicaciones distribuidas con capas.
Este capítulo incluye las siguientes secciones:
• Objetivos del diseño de aplicaciones distribuidas
• Servicios e integración de servicios
• Componentes y niveles en aplicaciones y servicios
• Escenario de ejemplo

4 Arquitectura de aplicaciones .NET: Diseño de aplicaciones y servicios
Objetivos del diseño de aplicaciones distribuidas
El diseño de una aplicación distribuida implica la toma de decisiones sobre su arquitectura lógica y física,
así como sobre la tecnología e infraestructura que se emplearán para implementar su funcionalidad. Para
tomar estas decisiones, debe tener un conocimiento claro de los procesos empresariales que realizará la
aplicación (sus requisitos funcionales), así como los niveles de escalabilidad, disponibilidad, seguridad y
mantenimiento necesarios (sus requisitos no funcionales, funcionales u operativos).
El objetivo consiste en diseñar una aplicación que:
• Solucione el problema empresarial para el que se diseña.
• Tenga en consideración la seguridad desde el principio, teniendo en cuenta los mecanismos
adecuados de autenticación, la lógica de autorización y la comunicación segura.
• Proporcione un alto rendimiento y esté optimizada para operaciones frecuentes entre patrones de
implementación.
• Esté disponible y sea resistente, capaz de implementarse en centros de datos de alta disponibilidad y
redundantes.
• Permita la escalabilidad para cumplir las expectativas de la demanda y admita un gran número de
actividades y usuarios con el mínimo uso de recursos.
• Se pueda administrar, permitiendo a los operadores implementar, supervisar y resolver los problemas
de la aplicación en función del escenario.
• Se pueda mantener. Cada parte de funcionalidad debería tener una ubicación y diseño predecibles
teniendo en cuenta distintos tamaños de aplicaciones, equipos con conjuntos de habilidades variadas
y requisitos técnicos y cambios empresariales.
• Funcione en los distintos escenarios de aplicaciones y patrones de implementación.
Las instrucciones de diseño que se ofrecen en los siguientes capítulos persiguen estos objetivos y explican
los motivos para las decisiones de un diseño en particular siempre que sea importante para entender su
fondo.
Servicios e integración de servicios
A medida que crece Internet y las tecnologías relacionadas, y las organizaciones buscan integrar sus
sistemas entre límites de departamentos y de organización, ha evolucionado un enfoque de generación de
soluciones basado en servicios. Desde el punto de vista del consumidor, los servicios son conceptualmente
similares a los componentes tradicionales, salvo que los servicios encapsulan sus propios datos y no
forman parte, estrictamente hablando, de la aplicación sino que son utilizados por ésta. Aplicaciones y
servicios que necesitan integrarse se pueden generar en distintas plataformas, por distintos equipos, en
diferentes programas y se pueden mantener y actualizar de forma independiente. Por tanto, es esencial
que implemente la comunicación entre ellos con el mínimo acoplamiento.

Se recomienda que implemente la comunicación entre los servicios empleando técnicas basadas en
mensajes para proporcionar altos niveles de solidez y escalabilidad. Puede implementar la comunicación
de mensajes de forma explícita (por ejemplo, escribiendo código para enviar y recibir mensajes de
Message Queue Server), o bien, puede utilizar componentes de infraestructuras que administran la
comunicación de forma implícita (por ejemplo, con un servidor proxy de servicios Web generado por
Microsoft Visual Studio® .NET).
Nota El término servicio se utiliza en esta guía para hacer referencia a los componentes de software
externos que proporcionan servicios empresariales. Esto incluye, aunque no exclusivamente, los servicios
Web XML.
Los servicios exponen una interfaz de servicios a la que se envían todos los mensajes entrantes. La
definición del conjunto de mensajes que se deben intercambiar con un servicio para que éste realice una
tarea empresarial específica constituye un contrato. Puede imaginarse una interfaz de servicios como una
fachada que expone la lógica empresarial implementada en el servicio para consumidores potenciales.
Por ejemplo, considere una aplicación comercial de venta a través de la cual los clientes solicitan
productos. La aplicación utiliza un servicio de autorización de tarjetas de crédito externas para validar los
detalles de la tarjeta de crédito del cliente y autorizar la venta. Una vez comprobados los datos de la
tarjeta de crédito, se utiliza un servicio de correo para organizar la entrega de los productos. El siguiente
diagrama de secuencias (Figura 1.1) muestra este escenario.
Figura 1.1. Proceso empresarial implementado utilizando servicios
En este escenario, el servicio de autorización de las tarjetas de crédito y el servicio de correo desempeñan
cada uno una función en el proceso empresarial global de compra. A diferencia de los componentes
ordinarios, los servicios existen en sus propios límites de confianza y administran sus propios datos, fuera
de la aplicación. Por tanto, debe estar seguro de establecer una conexión segura y autenticada entre la
aplicación de llamada y el servicio cuando utilice un enfoque basado en servicios para el desarrollo de
aplicaciones. Además, podría implementar la comunicación mediante el uso de un enfoque basado en
mensajes, haciendo el diseño más adecuado para describir procesos empresariales (a veces denominados
transacciones empresariales o transacciones de ejecución larga) y para el acoplamiento flexible de
sistemas que son frecuentes en soluciones distribuidas de gran tamaño, especialmente si el proceso
empresarial implica varias organizaciones y distintas plataformas.

Por ejemplo, si las comunicaciones basadas en mensajes se utilizan en el proceso mostrado en la figura
1.1, el usuario puede recibir la confirmación del pedido segundos u horas después de que se proporcionara
la información de venta, dependiendo de la capacidad de respuesta de los servicios de autorización y
entrega. La comunicación basada en mensajes permite también realizar el diseño de la lógica empresarial
de forma independiente al protocolo de transporte subyacente utilizado entre los servicios.
Si la aplicación utiliza un servicio externo, la implementación interna del servicio le es indiferente al
diseño; siempre que el servicio realice lo que se supone que debe realizar. Simplemente necesita saber la
funcionalidad empresarial que ofrece el servicio y los detalles del contrato que debe respetar para
comunicarse con el mismo (como el formato de comunicación, esquema de datos, mecanismo de
autenticación, etc.). En el ejemplo de la aplicación comercial, el servicio de autorización de tarjetas de
crédito ofrece una interfaz a través de la cual se pueden pasar al servicio los detalles sobre la venta y la
tarjeta de crédito, así como la respuesta indicando si se aprueba o no la venta. Desde la perspectiva del
diseñador de la aplicación comercial, lo que sucede dentro del servicio de autorización de tarjetas de
crédito es irrelevante; lo único que importa es determinar qué datos es necesario que se envíen al servicio,
qué respuestas se recibirán del servicio y cómo comunicarse con el servicio.
Internamente, los servicios contienen varios tipos de componentes comunes a las aplicaciones
tradicionales. (El resto de esta guía se centra en los distintos componentes y su función en el diseño de la
aplicación.) Los servicios contienen componentes de lógica que organizan las tareas empresariales que
realizan, los componentes empresariales que implementan la lógica empresarial real del servicio y los
componentes de acceso a datos que tienen acceso al almacén de datos del servicio. Además, los servicios
exponen sus funcionalidad a través de interfaces de servicio, que controlan la semántica utilizada para
exponer la lógica empresarial subyacente. La aplicación también llamará a otros servicios a través de los
agentes de servicios, que se comunican con el servicio de parte de la aplicación cliente que realiza la
llamada.
Aunque los servicios basados en mensajes se pueden diseñar para que se llamen sincrónicamente, puede
resultar ventajoso generar interfaces de servicios asincrónicos, que permiten un enfoque de acoplamiento
flexible en el desarrollo de aplicaciones distribuidas. El acoplamiento flexible que ofrece la comunicación
asincrónica posibilita la generación de soluciones de alta disponibilidad, escalabilidad y duración formadas
por servicios existentes. Sin embargo, un diseño asincrónico no proporciona estas ventajas de forma
gratuita: el uso de la comunicación asincrónica indica que el diseño puede necesitar tener en cuenta
consideraciones especiales como la correlación de mensajes, la administración de concurrencia de datos
optimista, la compensación de procesos empresariales y la no disponibilidad de servicios externos.
Nota El capítulo 3, "Directivas de seguridad, administración operativa y comunicaciones", trata con
mayor detalle los problemas que surgen en la implementación de la comunicación del servicio.
Para obtener más información sobre los servicios y los conceptos relacionados, consulte "Application
Conceptual View" (en inglés) en MSDN (http://msdn.microsoft.com/library/en-
us/dnea/html/eaappconland.asp).

Componentes y niveles en aplicaciones y servicios
Se ha convertido en un principio ampliamente aceptado en el diseño de aplicaciones distribuidas la división
de la aplicación en componentes que ofrezcan servicios de presentación, empresariales y de datos. Los
componentes que realizan tipos de funciones similares se pueden agrupar en capas, que en muchos casos
están organizados en forma de apilamiento para que los componentes que se encuentran por "encima" de
una capa determinada utilicen los servicios proporcionados por ésta, y un componente especifico utilizará
la funcionalidad proporcionada por otros componentes de su propia capa, y otras capas "inferiores", para
realizar su trabajo.
Nota Esta guía utiliza el término capa para hacer referencia a un tipo de componente y el término
nivel para hacer referencia a los patrones de distribución físicos.
Esta visión dividida de una aplicación también se puede aplicar a los servicios. Desde un punto de vista de
alto nivel, se puede considerar que la solución basada en servicios está formada por varios servicios, los
cuales se comunican entre sí pasando mensajes. Desde el punto de vista conceptual, los servicios se
pueden considerar como componentes de la solución global. Sin embargo, internamente el servicio está
formado por componentes de software, al igual que cualquier otra aplicación, los cuales se pueden
agrupar de forma lógica en servicios de presentación, empresariales y de datos, tal y como se muestra en
la figura 1.2.
Figura 1.2. Solución basada en servicios
Los aspectos importantes que se deben tener en cuenta de esta figura son los siguientes:

1. Los servicios se diseñan generalmente para comunicarse entre sí con el mínimo grado de
acoplamiento. El uso de la comunicación basada en mensajes ayuda a desacoplar la disponibilidad y
escalabilidad de los servicios, y basarse en los estándares de la industria, como los servicios Web XML,
permite la integración con las demás plataformas y tecnologías.
2. Cada servicio está formado por una aplicación que dispone de sus propios orígenes de datos, lógica
empresarial e interfaces de usuario. Un servicio puede presentar el mismo diseño interno que una
aplicación tradicional de tres niveles, por ejemplo, los servicios (2) y (4) de la figura anterior.
3. Puede generar y exponer un servicio que no disponga de una interfaz de usuario directamente
asociada (un servicio diseñado para que lo invoquen otras aplicaciones a través de una interfaz de
programación). Esto se muestra en el servicio (3). Observe que los componentes que forman un
servicio y los componentes que componen las capas empresariales de una aplicación se pueden
diseñar de forma similar.
4. Cada servicio encapsula sus propios datos y administra las transacciones atómicas con sus propios
orígenes de datos.
Es importante tener en cuenta que las capas son simplemente agrupaciones lógicas de los componentes
de software que conforman la aplicación o servicio. Ayudan a diferenciar entre los distintos tipos de tareas
que realizan los componentes, facilitando el diseño de la reutilización en la solución. Cada capa lógica
contiene un número de tipos de componentes discretos agrupados en subcapas, cada una de las cuales
realiza el mismo tipo de tarea específica. Al identificar los tipos genéricos de componentes que existen en
la mayoría de las soluciones, puede construir un mapa coherente de una aplicación o servicio y, a
continuación, utilizar este mapa como plano técnico para el diseño.
En la figura 1.3 se muestra una visión simplificada de una aplicación y sus capas.
Figura 1.3. Componentes separados en capas según sus funciones

Una solución distribuida puede que necesite abarcar varias organizaciones o niveles físicos, en cuyo caso
tendrá sus propias directivas en relación a la seguridad, administración operativa y comunicaciones de la
aplicación. Estas unidades de confianza, o zonas, pueden ser un nivel físico, un centro de datos o un
departamento, sección o empresa que tenga estas directivas definidas. Unidas, estas directivas definen
reglas para el entorno en el que se implementa la aplicación y la forma en que los niveles del servicio o
aplicación se comunican. Las directivas abarcan toda la aplicación y la forma en que se implementan
afecta a las decisiones sobre el diseño en cada nivel. También tienen un impacto entre sí (por ejemplo, la
directiva de seguridad determina algunas de las reglas en la directiva de comunicación y viceversa).
Nota Para obtener más información sobre el diseño de directivas de seguridad, administración
operativa y comunicaciones, consulte el capítulo 3, "Directivas de seguridad, administración operativa y
comunicaciones".
Escenario de ejemplo
Para ayudar a identificar los tipos frecuentes de componentes, esta guía describe una aplicación de
ejemplo que utiliza servicios externos. Aunque esta guía se centra en un ejemplo concreto, las
recomendaciones de diseño indicadas se aplican a la mayor parte de las aplicaciones distribuidas,
independientemente del escenario empresarial real.
El escenario descrito en esta guía es una extensión de la aplicación comercial descrita anteriormente en
este capítulo. En este escenario, una empresa de venta al por menor ofrece a sus clientes la posibilidad de
solicitar productos a través de un sitio Web de comercio electrónico o por teléfono. Los usuarios de
Internet pueden visitar el sitio Web de la compañía y seleccionar productos de un catálogo en línea. De
forma alternativa, los clientes pueden solicitar productos de una catálogo de pedidos por correo mediante
una llamada por teléfono a un representante de ventas, que indica los detalles del pedido a través de una
aplicación basada en Microsoft Windows. Una vez finalizado un pedido, los detalles de la tarjeta de crédito
del cliente se autorizan mediante un servicio de tarjetas de crédito externo y la entrega se organiza a
través de un servicio de correo externo.
La solución propuesta para este escenario es un diseño basado en componentes compuesto por una serie
de componentes, tal y como se muestra en la figura 1.4.

Figura 1.4. La aplicación comercial es un conjunto de componentes y servicios relacionados
En la figura 1.4 se muestra la aplicación comercial compuesta por varios componentes de software, que se
agrupan en niveles lógicos según el tipo de funcionalidad que proporcionan. Observe que desde el punto
de vista de la aplicación comercial, los servicios de autorización de tarjetas de crédito y de correo se
pueden considerar componentes externos. Sin embargo, internamente los servicios se implementan más
como las aplicaciones normales y contienen los mismos tipos de componentes (aunque los servicios de
este escenario no contienen un nivel de presentación, sino que publican su funcionalidad a través de una
interfaz de servicios mediante programación).
© 2003 Microsoft Corporation. Reservados todos los derechos. Condiciones de uso.

Capítulo 2: Diseño de los componentes de una aplicación o
servicios
Diciembre de 2002

Capítulo 2: Diseño de los componentes de una aplicación o servicios
Resumen: en este capítulo se describen los distintos tipos de componentes que se pueden encontrar en
una aplicación o servicio .NET distribuido, así como las prácticas más efectivas para su diseño.
Este capítulo incluye las siguientes secciones:
• Tipos de componentes
• Recomendaciones generales relativas al diseño de aplicaciones y servicios
• Diseño de capas de presentación
• Diseño de capas empresariales
• Diseño de capas de datos
Tipos de componentes
El análisis de la mayoría de las soluciones empresariales basadas en modelos de componentes por capas
muestra que existen varios tipos de componentes habituales. En la figura 2.1 se muestra una ilustración
completa en la que se indican estos tipos de componentes.
Nota El término componente hace referencia a una de las partes de la solución total, como los
componentes de software compilado (por ejemplo, los ensamblados de Microsoft .NET) y otros elementos
de software, como las páginas Web y los programas de Microsoft® BizTalk® Server Orchestration.
Aunque la lista que se muestra en la figura 2.1 no es completa, representa los tipos de componentes de
software más comunes encontrados en la mayoría de las soluciones distribuidas. A lo largo de este
capítulo describiremos en profundidad cada uno de estos tipos.

Figura 2.1. Tipos de componentes utilizados en el escenario comercial de ejemplo
Los tipos de componentes identificados en el escenario de diseño de ejemplo son:
1. Componentes de interfaz de usuario (IU). La mayor parte de las soluciones necesitan ofrecer al
usuario un modo de interactuar con la aplicación. En el ejemplo de aplicación comercial, un sitio Web
permite al cliente ver productos y realizar pedidos, y una aplicación basada en el entorno operativo
Microsoft Windows® permite a los representantes de ventas escribir los datos de los pedidos de los
clientes que han telefoneado a la empresa. Las interfaces de usuario se implementan utilizando
formularios de Windows Forms, páginas Microsoft ASP.NET, controles u otro tipo de tecnología que
permita procesar y dar formato a los datos de los usuarios, así como adquirir y validar los datos
entrantes procedentes de éstos.
2. Componentes de proceso de usuario. En un gran número de casos, la interacción del usuario con
el sistema se realiza de acuerdo a un proceso predecible. Por ejemplo, en la aplicación comercial,
podríamos implementar un procedimiento que permita ver los datos del producto. De este modo, el
usuario puede seleccionar una categoría de una lista de categorías de productos disponibles y, a
continuación, elegir uno de los productos de la categoría seleccionada para ver los detalles
correspondientes. Del mismo modo, cuando el usuario realiza una compra, la interacción sigue un
proceso predecible de recolección de datos por parte del usuario, por el cual éste en primer lugar
proporciona los detalles de los productos que desea adquirir, a continuación los detalles de pago y,
por último, la información para el envío. Para facilitar la sincronización y organización de las

interacciones con el usuario, resulta útil utilizar componentes de proceso de usuario individuales. De
este modo, el flujo del proceso y la lógica de administración de estado no se incluye en el código de
los elementos de la interfaz de usuario, por lo que varias interfaces podrán utilizar el mismo "motor"
de interacción básica.
3. Flujos de trabajo empresariales. Una vez que el proceso de usuario ha recopilado los datos
necesarios, éstos se pueden utilizar para realizar un proceso empresarial. Por ejemplo, tras enviar los
detalles del producto, el pago y el envío a la aplicación comercial, puede comenzar el proceso de
cobro del pago y preparación del envío. Gran parte de los procesos empresariales conllevan la
realización de varios pasos, los cuales se deben organizar y llevar a acabo en un orden determinado.
Por ejemplo, el sistema empresarial necesita calcular el valor total del pedido, validar la información
de la tarjeta de crédito, procesar el pago de la misma y preparar el envío del producto. El tiempo que
este proceso puede tardar en completarse es indeterminado, por lo que sería preciso administrar las
tareas necesarias, así como los datos requeridos para llevarlas a cabo. Los flujos de trabajo
empresariales definen y coordinan los procesos empresariales de varios pasos de ejecución larga y se
pueden implementar utilizando herramientas de administración de procesos empresariales, como
BizTalk Server Orchestration.
4. Componentes empresariales. Independientemente de si el proceso empresarial consta de un único
paso o de un flujo de trabajo organizado, la aplicación requerirá probablemente el uso de
componentes que implementen reglas empresariales y realicen tareas empresariales. Por ejemplo, en
la aplicación comercial, deberá implementar una funcionalidad que calcule el precio total del pedido y
agregue el costo adicional correspondiente por el envío del mismo. Los componentes empresariales
implementan la lógica empresarial de la aplicación.
5. Agentes de servicios. Cuando un componente empresarial requiere el uso de la funcionalidad
proporcionada por un servicio externo, tal vez sea necesario hacer uso de código para administrar la
semántica de la comunicación con dicho servicio. Por ejemplo, los componentes empresariales de la
aplicación comercial descrita anteriormente podría utilizar un agente de servicios para administrar la
comunicación con el servicio de autorización de tarjetas de crédito y utilizar un segundo agente de
servicios para controlar las conversaciones con el servicio de mensajería. Los agentes de servicios
permiten aislar las idiosincrasias de las llamadas a varios servicios desde la aplicación y pueden
proporcionar servicios adicionales, como la asignación básica del formato de los datos que expone el
servicio al formato que requiere la aplicación.
6. Interfaces de servicios. Para exponer lógica empresarial como un servicio, es necesario crear
interfaces de servicios que admitan los contratos de comunicación (comunicación basada en mensajes,
formatos, protocolos, seguridad y excepciones, entre otros) que requieren los clientes. Por ejemplo,
el servicio de autorización de tarjetas de crédito debe exponer una interfaz de servicios que describa
la funcionalidad que ofrece el servicio, así como la semántica de comunicación requerida para llamar
al mismo. Las interfaces de servicios también se denominan fachadas empresariales.
7. Componentes lógicos de acceso a datos. La mayoría de las aplicaciones y servicios necesitan
obtener acceso a un almacén de datos en un momento determinado del proceso empresarial. Por
ejemplo, la aplicación empresarial necesita recuperar los datos de los productos de una base de datos
para mostrar al usuario los detalles de los mismos, así como insertar dicha información en la base de

datos cuando un usuario realiza un pedido. Por tanto, es razonable abstraer la lógica necesaria para
obtener acceso a los datos en un capa independiente de componentes lógicos de acceso a datos, ya
que de este modo se centraliza la funcionalidad de acceso a datos y se facilita la configuración y el
mantenimiento de la misma.
8. Componentes de entidad empresarial. La mayoría de la aplicaciones requieren el paso de datos
entre distintos componentes. Por ejemplo, en la aplicación comercial es necesario pasar una lista de
productos de los componentes lógicos de acceso a datos a los componentes de la interfaz de usuario
para que éste pueda visualizar dicha lista. Los datos se utilizan para representar entidades
empresariales del mundo real, como productos o pedidos. Las entidades empresariales que se utilizan
de forma interna en la aplicación suelen ser estructuras de datos, como conjuntos de datos,
DataReader o secuencias de lenguaje de marcado extensible (XML), aunque también se pueden
implementar utilizando clases orientadas a objetos personalizadas que representan entidades del
mundo real necesarias para la aplicación, como productos o pedidos.
9. Componentes de seguridad, administración operativa y comunicación. La aplicación
probablemente utilice también componentes para realizar la administración de excepciones, autorizar
a los usuarios a que realicen tareas determinadas y comunicarse con otros servicios y aplicaciones.
Estos componentes se describen en detalle en el capítulo 3: "Directivas de seguridad, administración
operativa y comunicaciones".
Recomendaciones generales relativas al diseño de aplicaciones y servicios
Tenga en cuenta las siguientes recomendaciones al diseñar una aplicación o servicio:
• Identifique los distintos tipos de componentes que necesitará utilizar en la aplicación. Ciertas
aplicaciones no requieren el uso de determinados componentes. Por ejemplo, puede que las
aplicaciones de menor tamaño que no necesitan integrarse con otros servicios no requieran flujos de
trabajo empresariales ni agentes de servicios. Así mismo, puede que las aplicaciones que sólo
disponen de una interfaz de usuario y un número pequeño de elementos no requieran componentes
de proceso de usuario.
• Intente que el diseño de todos los componentes pertenecientes a un mismo tipo sea coherente. Utilice
un único modelo de diseño o un volumen bajo de modelos. Esto facilita la conservación de la
previsibilidad y el mantenimiento del diseño y la implementación por parte de todos los equipos. En
determinados casos, puede resultar difícil mantener un diseño lógico debido a entornos técnicos (por
ejemplo, si desarrolla interfaces de usuario basadas tanto en ASP.NET como en Windows). No
obstante, debe esforzarse al máximo en mantener la coherencia dentro de cada entorno. En
ocasiones, puede utilizar una clase base para todos los componentes que sigan un patrón similar,
como los componentes lógicos de acceso a datos.
• Analice el modo en que los componentes se comunican entre sí antes de elegir los límites físicos de
distribución. Mantenga un nivel bajo de agrupación y un alto grado de cohesión. Para ello, elija
interfaces de carácter general, en lugar de tipo "chatty", para las comunicaciones remotas.

• Mantenga la coherencia en la aplicación o el servicio en cuanto al formato utilizado para el
intercambio de datos. Si a pesar de todo debe utilizar varios formatos de representación de datos,
utilice el menor número que pueda. Por ejemplo, puede devolver datos en un elemento DataReader
de los componentes lógicos de acceso a datos para llevar a cabo el procesamiento rápido de los datos
en Microsoft ASP.NET, pero hacer uso de conjuntos de datos para el consumo en los procesos
empresariales. No obstante, tenga en cuenta que utilizar cadenas XML, conjuntos de datos, objetos
serializados, elementos DataReader y otro tipo de formatos en la misma aplicación dificultará el
desarrollo, la extensibilidad y el mantenimiento de la misma.
• Abstraiga el código que aplica las políticas (como la de seguridad, administración operativa y
restricciones de comunicación) de la lógica empresarial de la aplicación. Intente basarse en atributos,
interfaces de programación de aplicaciones (API) de plataforma o componentes de utilidades que
proporcionen acceso de una "única línea de código" a la funcionalidad relacionada con las políticas,
como la publicación de excepciones y la autorización de usuarios, entre otras.
• Determine en la fase inicial del proceso el tipo de capas que desea aplicar. En un sistema de capas
estricto, los componentes de la capa A no pueden llamar a los componentes de la capa C; siempre
llaman a los componentes de la capa B. Sin embargo, en un sistema de capas con un nivel más alto
de flexibilidad, los componentes de una capa pueden llamar a los componentes de otras capas que no
se encuentran inmediatamente por debajo de ella. En cualquier caso, intente evitar las llamadas y
dependencias ascendentes, en las que la capa C invoca a la capa B. Implemente un sistema de capas
flexible para evitar los efectos cascada que tienen lugar cuando una capa de los niveles inferiores
cambia, o para evitar tener componentes que sólo realizan llamadas hacia adelante a capas inferiores.
Diseño de capas de presentación
La capa de presentación contiene los componentes necesarios para habilitar la interacción del usuario con
la aplicación. Las capas de presentación más simples contienen componentes de interfaz, como
formularios de Windows Forms o formularios Web de ASP.NET. Las interacciones más complejas conllevan
el diseño de componentes de proceso de usuario que permiten organizar los elementos de la interfaz y
controlar la interacción con el usuario. Los componentes de proceso de usuario resultan especialmente
útiles cuando la interacción del usuario sigue una serie de pasos predecibles, como al utilizar un asistente
para realizar una tarea determinada. En la figura 2.2 se muestran los tipos de componentes presentes en
la capa de presentación.

Figura 2.2. Capa de presentación
En el caso de la aplicación comercial, son necesarias dos interfaces de usuario: una para el sitio Web de
comercio electrónico que utiliza el cliente y otra para las aplicaciones basadas en formularios de Windows
Forms utilizados por los representantes de ventas. Ambos tipos de usuario realizan tareas similares a
través de estas interfaces. Por ejemplo, ambas interfaces deben permitir ver todos los productos
disponibles, agregar productos a una cesta de compra y especificar los detalles de pago como parte de un
proceso de desprotección. Este proceso se puede realizar a parte en un componente de proceso de usuario
independiente para facilitar el mantenimiento de la aplicación.
Diseño de componentes de interfaz de usuario
La implementación de interfaces de usuario se puede llevar a cabo de varias formas. Por ejemplo, la
aplicación comercial requiere una interfaz basada en el Web y otra basada en Windows. Otros tipos de
interfaces de usuario incluyen procesamiento de voz, programas basados en documentos y aplicaciones de
cliente móviles, entre otros. Los componentes de la interfaz de usuario administran la interacción con el
usuario. Muestran los datos al usuario, obtienen los datos del mismo e interpretan los eventos generados
por el usuario para actuar en los datos empresariales, cambiar el estado de la interfaz o facilitar la tarea al
usuario.
Las interfaces de usuario constan normalmente de una página o formulario con varios elementos que
permiten mostrar datos y aceptar la entrada del usuario. Por ejemplo, una aplicación basada en Windows

puede contener un control DataGrid que muestre una lista de categorías de productos y un control de
botón de comando que indica que el usuario desea ver los productos de la categoría seleccionada. Cuando
un usuario interactúa con un elemento de la interfaz, se genera un evento que llama al código de una
función de control. Ésta, a su vez, llama a componentes empresariales, componentes lógicos de acceso a
datos o componentes de proceso de usuario para implementar la acción deseada y recuperar los datos que
se han de mostrar. A continuación, la función de control actualiza los elementos de la interfaz. En la figura
2.3 se muestra el diseño de una interfaz de usuario.
Figura 2.3. Diseño de interfaz de usuario
Funcionalidad de los componentes de interfaz de usuario
Los componentes de la interfaz de usuario deben mostrar datos al usuario, obtener y validar los datos
procedentes del mismo e interpretar las acciones de éste que indican que desea realizar una operación
con los datos. Asimismo, la interfaz debe filtrar las acciones disponibles con el fin de permitir al usuario
realizar sólo aquellas operaciones que le sean necesarias en un momento determinado.
Los componentes de interfaz de usuario:
• No inicializan, participan ni votan en transacciones.
• Presentan una referencia al componente de proceso de usuario actual si necesitan mostrar sus datos
o actuar en su estado.
• Pueden encapsular tanto la funcionalidad de visualización como un controlador.
Al aceptar la entrada del usuario, los componentes de la interfaz:
• Adquieren los datos del usuario y atienden su entrada utilizando guías visuales (como informaciones
sobre herramientas) y sistemas de validación, así como los controles necesarios para realizar la tarea
en cuestión.
• Capturan los eventos del usuario y llaman a las funciones de control para indicar a los elementos de
la interfaz de usuario que cambien el modo de visualización de los datos, bien inicializando una acción
en el proceso de usuario actual, o bien, modificando los datos del mismo.
• Restringen los tipos de entrada del usuario. Por ejemplo, un campo Quantity puede limitar las
entradas del usuario a valores numéricos.
• Realizan la validación de entrada de datos, por ejemplo, restringiendo el intervalo de valores que se
pueden escribir en un campo determinado, o garantizando que se escriben los datos obligatorios.

• Llevan a cabo la asignación y transformación simple de la información proporcionada por los controles
del usuario en los valores necesarios para que los componentes subyacentes realicen su trabajo (por
ejemplo, un componente de interfaz de usuario puede mostrar el nombre de un producto pero pasar
el Id. del mismo a los componentes subyacentes).
• Interpretar las acciones del usuario (como las operaciones de arrastrar y colocar o los clics de
botones) y llamar a una función de control.
• Pueden utilizar un componente de utilidad para el almacenamiento de datos en caché. En ASP.NET,
puede especificar el almacenamiento en caché de la salida de un componente determinado de la
interfaz de usuario para evitar el continuo procesamiento del mismo. Si la aplicación contiene
elementos visuales que representan datos de referencia que no cambian con frecuencia y no se
utilizan en contextos transaccionales, y un gran número de usuarios comparte dichos elementos, se
recomienda que los almacene en caché. Se aconseja almacenar en caché aquellos elementos visuales
compartidos por un gran número de usuarios, que representan datos de referencia que no cambian
con frecuencia y no se utilizan en contextos transaccionales.
• Pueden utilizar un componente de utilidad para realizar la paginación. Es frecuente, especialmente en
las aplicaciones Web, mostrar largas listas de datos como conjuntos paginados. Asimismo, se suele
disponer de un componente de ayuda para realizar el seguimiento de la página actual en la que se
encuentra el usuario y, por tanto, invocar a las funciones de consulta paginada de los componentes
lógicos de acceso a datos con los valores adecuados relativos al tamaño de página y página actual. La
paginación se puede realizar sin la interacción del componente de proceso de usuario.
Al procesar datos, los componentes de interfaz de usuario:
• Adquieren y procesan los datos de los componentes empresariales o de los componentes lógicos de
acceso a datos de la aplicación.
• Realizan el formato de valores (como el formato adecuado de las fechas).
• Realizan las tareas de localización de los datos procesados (por ejemplo, utilizando cadenas de
recursos para mostrar los encabezados de las columnas de una cuadrícula en el idioma
correspondiente a la configuración regional del usuario).
• Normalmente, procesan los datos de una entidad empresarial. Estas entidades se suelen obtener del
componente de proceso de usuario, aunque también se pueden obtener de los componentes de datos.
Los componentes de IU pueden procesar datos a través del enlace a datos de su visualización con los
atributos y colecciones adecuados de los componentes de la entidad, sí ésta se encuentra disponible.
Si se encuentra administrando los datos de una entidad como conjuntos de datos, esta tarea resulta
bastante sencilla. Si ha implementado objetos de entidad personalizados, tal vez sea preciso
implementar código adicional para facilitar el enlace a datos.
• Proporcionan la información de estado al usuario, por ejemplo, indicando cuando una aplicación se
encuentra en modo "desconectado" o "conectado".

• Pueden personalizar el aspecto de la aplicación en función de las preferencias del usuario o el tipo de
dispositivo de cliente utilizado.
• Pueden utilizar un componente de utilidad para proporcionar funcionalidad de deshacer. Un gran
número de aplicaciones deben permitir al usuario deshacer determinadas operaciones. Esto se realiza
normalmente manteniendo una pila de datos de longitud fija de tipo "valor antiguo, valor nuevo" para
elementos específicos de datos o entidades completas. Cuando una operación conlleva un proceso
empresarial, se recomienda que no exponga la compensación como una función de deshacer simple,
sino como una operación explícita.
• Pueden utilizar un componente de utilidad para proporcionar funcionalidad de portapapeles. En gran
parte de las aplicaciones basadas en Windows, resulta útil proporcionar capacidades de portapapeles
no sólo para valores escalares; por ejemplo, tal vez desee permitir a los usuarios que copien y
peguen un objeto completo de cliente. Esta funcionalidad se implementa normalmente colocando
cadenas XML en el Portapapeles de Windows, o bien, disponiendo de un objeto global que mantiene
los datos en memoria si el portapapeles es específico de la aplicación.
Interfaces de usuario del Escritorio de Windows
Las interfaces de usuario de Windows se utilizan cuando es necesario proporcionar capacidades de
desconexión o fuera de línea, o interacción enriquecida de usuario, o incluso integración con las interfaces
de usuario de otras aplicaciones. Las interfaces de usuario de Windows pueden beneficiarse de una amplia
gama de opciones de administración y persistencia de estado y pueden hacer uso de la potencia de
procesamiento local. Existen tres familias principales de interfaces de usuario independientes: aplicaciones
basadas en Windows "completas", aplicaciones basadas en Windows que incluyen contenido HTML
incrustado y complementos de aplicación que se utilizan en la interfaz de usuario de las aplicaciones host:
• Interfaces de usuario completas de PC de escritorio o Tablet PC incorporadas en Windows
Forms
La creación de una aplicación basada en Windows conlleva la inclusión en dicha aplicación de
formularios de Windows Forms y controles a través de los cuales la aplicación ofrezca toda o la mayor
parte de la funcionalidad de procesamiento de datos. Esto le proporciona un alto nivel de control
sobre la interfaz de usuario y el control total sobre la apariencia y el funcionamiento de la aplicación.
No obstante, este hecho le ata a una plataforma de cliente y hace necesario implementar la aplicación
a los usuarios (incluso si la implementación de la aplicación se realiza a través de la descarga de la
misma desde una conexión HTTP).
• HTML incrustado
Puede implementar la interfaz de usuario completa utilizando Windows Forms, o bien, en las
aplicaciones basadas en Windows, puede utilizar HTML incrustado adicional. El contenido HTML
incrustado aporta un mayor nivel de flexibilidad en tiempo de ejecución (ya que dicho contenido se
puede cargar desde recursos externos o incluso, en escenarios conectados, desde una base de datos)
y permite personalizar la aplicación en función de las necesidades del usuario. Sin embargo, debe
considerar detenidamente el modo de evitar que secuencias de comandos malintencionadas penetren

en el HTML. Asimismo, será preciso hacer uso de código adicional para cargar el HTML, mostrarlo y
enlazar los eventos del control con las funciones de la aplicación.
• Complementos de aplicación
La experiencia puede sugerir que la implementación de la interfaz de usuario es más adecuada si se
realiza como un complemento de otras aplicaciones, como Microsoft Office, AutoCAD, las soluciones
de los servicios de administración de relaciones con los clientes (Customer Relationship Management,
CRM), herramientas de ingeniería, etc. En este caso, puede hacer uso de la lógica de adquisición y
visualización de datos de la aplicación host y ofrecer sólo el código necesario para recopilar los datos
y trabajar con su lógica empresarial.
La mayoría de las aplicaciones modernas admiten complementos, bien como objetos COM (Modelo de
objetos componentes) u objetos .NET compatibles con una interfaz específica, o bien, como entornos
de desarrollo incrustados (como el sistema de desarrollo Microsoft Visual Basic®, compatible con la
mayor parte de las aplicaciones basadas en Windows más utilizadas), que pueden, a su vez, invocar a
objetos personalizados. Determinados entornos incrustados (como Visual Basic) ofrecen incluso un
motor de formularios que permite agregar a la interfaz de usuario más funcionalidad que la
proporcionada por la aplicación host. Si desea obtener más información sobre el uso de Visual Basic
en aplicaciones host, consulte "Microsoft Visual Basic for Applications and Windows DNA 2000" (en
inglés) en MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dndna/html/vba4dna.asp).
Si desea obtener más información sobre el uso de .NET desde Microsoft Office, consulte "Microsoft
Office and .NET Interoperability" (en inglés) en MSDN
(http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnofftalk/html/office11012001.asp).
Tenga en cuenta las siguientes recomendaciones al crear aplicaciones basadas en Windows Forms:
• Básese en el enlace a datos para mantener la sincronización de los mismos en varios formularios
abiertos de forma simultánea. De este modo, disminuirá la necesidad de escribir código complejo de
sincronización de datos.
• Intente evitar las relaciones de modificación entre formularios y básese en el componente de proceso
de usuario para abrirlos y sincronizar los datos y eventos. Sea especialmente cuidadoso en evitar este
tipo de relaciones entre los formularios secundarios y primarios. Por ejemplo, la ventana de detalles
de un producto determinado se puede volver a utilizar en otras ubicaciones de la aplicación, no sólo
en un formulario de entrada de pedido, por lo que debe evitar la implementación de funcionalidad en
el formulario de detalles del producto que enlaza directamente al formulario de entrada del pedido.
Esto aumenta el nivel de reutilización de los elementos de la interfaz de usuario.
• Implemente controladores de errores en sus formularios para evitar que el usuario vea una ventana
de excepciones .NET no descriptiva y que la aplicación dé error si las excepciones no se controlan en
ninguna otra ubicación. Todos los controladores de eventos y las funciones de control deben incluir

capturas de excepciones. Asimismo, tal vez desee crear una clase de excepción personalizada para la
interfaz de usuario que incluya metadatos para determinar si la operación errónea se puede recuperar
o cancelar.
• Valide la entrada del usuario en la interfaz de usuario. La validación debe tener lugar en las fases de
la tarea o del proceso del usuario en las que se permiten las validaciones a un momento dado (lo que
posibilita al usuario escribir los datos necesarios, continuar con otra tarea y volver a la tarea actual).
En determinados casos, se recomienda habilitar o deshabilitar de forma proactiva los controles y guiar
de modo visual al usuario en caso de que se escriban datos no válidos. La validación de la entrada del
usuario en la interfaz evita recorridos de ida y vuelta innecesarios a los componentes del lado del
servidor al escribir datos no válidos.
• Si crea controles de usuario personalizados, exponga sólo las propiedades y los métodos públicos que
realmente necesita con el fin de facilitar el mantenimiento de los componentes.
• Implemente las funciones de control como funciones independientes en los formularios de Windows
Forms o en las clases .NET que se van a implementar con el cliente. No implemente la funcionalidad
de control directamente en los controladores de eventos de control. Si escribe la lógica de control en
controladores de eventos, reducirá la facilidad de mantenimiento de la aplicación, ya que en el futuro
tal vez sea necesario invocar a la misma función desde otros eventos.
Por ejemplo, el controlador de eventos de un botón de comando, denominado evento de clic de
addItem, debe llamar a un procedimiento más general para realizar su tarea, tal y como se muestra
en el siguiente código.
private void addItem_Click(object sender, System.EventArgs e)
{
AddItemToBasket(selectedProduct, selectedQuantity)
}
public void AddItemToBasket(int ProductID, int Quantity)
{
// código para agregar el artículo a la cesta
}
Interfaces de usuario de exploración de Internet

La aplicación comercial descrita en esta guía requiere una interfaz de usuario basada en el Web que
permita a los clientes realizar pedidos a través de Internet. Las interfaces de usuario basadas en el Web
permiten el uso de interfaces de usuario basadas en estándares en un gran número de dispositivos y
plataformas. Para desarrollar interfaces de usuario basadas en el Web para aplicaciones basadas en .NET
se utiliza ASP.NET. Éste ofrece un entorno enriquecido en el que se pueden crear interfaces complejas
basadas en el Web con compatibilidad para características importantes, como por ejemplo:
• Un entorno de desarrollo coherente que también se utiliza para crear otros componentes de la
aplicación.
• Enlace a datos de interfaz de usuario.
• Interfaces de usuario basadas en componentes con controles.
• Acceso al modelo de seguridad .NET integrado.
• Almacenamiento en caché enriquecido y opciones de administración de estado.
• Disponibilidad, rendimiento y escalabilidad del procesamiento Web.
Cuando necesite implementar una aplicación para un explorador, ASP.NET ofrece la funcionalidad
necesaria para publicar una interfaz de usuario basada en páginas Web. Considere las siguientes
recomendaciones relativas al diseño de interfaces de usuario de ASP.NET:
• Implemente una página de error personalizada y un controlador de excepciones global en Global.asax.
De este modo, dispondrá de una función completa de detección de excepciones que evitará que el
usuario vea páginas no descriptivas en caso de que ocurra algún problema.
• ASP.NET presenta un marco de validación enriquecido que optimiza la tarea de garantizar que los
datos escritos por el usuario se ajusten a determinados criterios. No obstante, la validación de
clientes que se realiza en el explorador se basa en que JavaScript está habilitado en el cliente, por lo
que también debe validar los datos en las funciones de control, en caso de que un usuario disponga
de un explorador no compatible con JavaScript (o tenga JavaScript deshabilitado). Si su proceso de
usuario dispone de una función de control de validación, llámelo antes de pasar a otras páginas para
llevar a cabo la validación a un momento dado.
• Si crea controles de usuario Web, exponga sólo las propiedades y los métodos públicos que realmente
necesita. De este modo, aumentará la facilidad del mantenimiento.
• Utilice el estado de vista de ASP.NET para almacenar el estado específico de las páginas y mantener
el estado de sesión y aplicación de los datos con un alcance más amplio. Este enfoque facilita el
mantenimiento y aumenta el nivel de escalabilidad.
• Las funciones de control deben invocar a las acciones del componente de proceso de usuario para
guiar al usuario a través de la tarea actual, en lugar de redireccionarlo a la página directamente. El
componente del proceso de usuario puede llamar a la función Redirect para que el servidor muestre
una página diferente. Para ello, debe hacer referencia al espacio de nombres System.Web desde los
componentes de proceso de usuario. (Tenga en cuenta que, por tanto, el componente de proceso de

usuario no se podrá volver a utilizar en aplicaciones basadas en el Web, por lo que resulta adecuado
implementar llamadas de redirección en una clase diferente).
• Implemente las funciones de control como funciones independientes en las páginas ASP.NET o en las
clases .NET que se distribuirán con las páginas Web. Si escribe la lógica empresarial en los
controladores de eventos proporcionados por ASP.NET, reducirá la facilidad de mantenimiento del
sitio, ya que tal vez sea necesario en el futuro invocar a la misma función desde otros eventos. Para
ello, se requiere una mayor capacidad por parte de los desarrolladores que escriben código exclusivo
de IU.
Suponga, por ejemplo, que el sitio Web comercial contiene una página en la que se puede hacer clic
en un botón de comando para agregar un producto a la cesta de compra del usuario. El marcado
ASP.NET del control podría tener el aspecto de la siguiente línea de código.
<asp:Button id="addItem" OnClick="addItem_Click"/>
Como puede observar en el código, la función addItem_Click controla el evento OnClick del botón. No
obstante, el controlador de eventos no debe contener el código que realiza la acción requerida (en
este caso, agregar un elemento de la cesta), sino que debe llamar a otra función general, como se
muestra en el siguiente fragmento de código.
private void addItem_Click(object sender, System.EventArgs e)
{
AddItemToBasket(selectedProduct, selectedQuantity)
}
public void AddItemToBasket(int ProductID, int Quantity)
{
// código para agregar el artículo a la cesta
}
Esta capa de abstracción adicional garantiza que otros elementos de la interfaz de usuario puedan
utilizar el código requerido para realizar las tareas de control.

Si desea obtener información general sobre ASP.NET, consulte la sección de ASP.NET (en inglés) de MSDN
(http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000440) y el sitio
oficial de ASP.NET (en inglés) (http://asp.net).
En un gran número de aplicaciones, resulta importante proporcionar un marco extensible en el que se
muestren varios paneles con diferentes objetivos. En las aplicaciones basadas en el Web, también es
preciso proporcionar una página principal o interfaz de usuario raíz en la que se muestren las tareas y la
información relevante al usuario en función del contexto y dispositivo utilizado. Microsoft proporciona los
siguientes recursos para facilitar la implementación de portales basados en el Web:
• Microsoft Content Management Server (en inglés)
(http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001368)
• Microsoft SharePoint Portal™ Server 2001 (en inglés)
us/spssdk/html/_welcome_to_tahoe.asp)
• IBuySpy Portal (en inglés)
(http://msdn.microsoft.com/library/en-us/dnbda/html/bdasampibsport.asp)
Interfaces de usuario de dispositivos móviles
Los dispositivos móviles, como los PC de mano, los teléfonos WAP (protocolo de aplicaciones inalámbricas)
y los dispositivos iMode, están adquiriendo cada vez una mayor popularidad. La creación de interfaces de
usuario para un factor de forma móvil presenta sus propios retos.
En general, la interfaz de usuario de un dispositivo móvil necesita ser capaz de mostrar la información en
una pantalla de un tamaño considerablemente menor al de las aplicaciones habituales y debe ofrecer un
nivel aceptable de uso para los dispositivos de destino. Debido a que la interacción del usuario puede
resultar un tanto incómoda en un gran número de dispositivos móviles, sobre todo en el caso de los
teléfonos móviles, procure diseñar las interfaces de usuario minimizando al máximo los requisitos de
entrada de datos. Una estrategia comúnmente utilizada consiste en combinar el uso de los dispositivos
móviles con una aplicación de tamaño completo basada en el Web o en Windows, permitir a los usuarios
que registren datos previamente a través del cliente basado en el escritorio y, a continuación,
seleccionarlos utilizando el cliente móvil. Por ejemplo, una aplicación de comercio electrónico puede
permitir a los usuarios que registren los datos de sus tarjetas de crédito a través del sitio Web. De este
modo, el usuario puede seleccionar una tarjeta de crédito previamente registrada de una lista cuando
realice un pedido desde un dispositivo móvil (evitando de este modo la necesidad de escribir los detalles
completos de la tarjeta de crédito a través del teclado numérico del teléfono o el lápiz de una agenda
personal digital [PDA]).
Interfaces de usuario Web
Una amplia gama de dispositivos móviles admiten la exploración de Internet. Algunos dispositivos utilizan
microexploradores que admiten un subconjunto de HTML 3.2, otros requieren el envío de datos en

lenguaje de marcado inalámbrico (WML) y otros admiten estándares como Compact HTML (cHTML). Puede
utilizar Microsoft Mobile Internet Toolkit para crear aplicaciones Web basadas en ASP.NET que envíen el
estándar de marcado adecuado a cada cliente en función del tipo de dispositivo, tal y como se identifica en
el encabezado de la solicitud. Esto permite crear una única aplicación Web dirigida a un gran número de
clientes móviles diferentes, incluidos Pocket PC, teléfonos WAP y teléfonos iMode, entre otros.
Al igual que con otros tipos de interfaz de usuario, debe intentar minimizar la posibilidad de que los
usuarios escriban datos no válidos en una página Web móvil. Mobile Internet Toolkit incluye controles de
validación del lado del cliente, como CompareValidator, CustomValidator, RegularExpressionValidator y
RequiredFieldValidator, que pueden utilizar varios tipos de dispositivos de cliente. Asimismo, puede utilizar
las propiedades de los campos de entrada, como los controles Textbox, para limitar el tipo de entrada
aceptada (por ejemplo, aceptando sólo entradas numéricas). No obstante, siempre debe permitir el uso de
dispositivos de cliente que puedan no ser compatibles con la validación del lado del cliente y realizar
comprobaciones adicionales una vez que los datos se han expuesto al servidor.
Si desea obtener más información sobre Mobile Internet Toolkit, consulte la página de Microsoft Mobile
Internet Toolkit (en inglés) en MSDN (http://msdn.microsoft.com/vstudio/device/mitdefault.asp).
Interfaces de usuario de dispositivos inteligentes
Pocket PC es un dispositivo basado en el sistema operativo Windows CE. Ofrece una gran número de
características y permite desarrollar interfaces de usuario desconectadas y conectadas (normalmente de
forma inalámbrica). La plataforma Pocket PC incluye dispositivos PDA de mano y teléfonos inteligentes,
que combinan las características de los PDA y los teléfonos convencionales.
Microsoft ofrece .NET Compact Framework para Pocket PC y otras plataformas Windows CE. Compact
Framework contiene un subconjunto de .NET Framework completo y permite el desarrollo de aplicaciones
completas basadas en .NET para dispositivos móviles. Los desarrolladores pueden utilizar Smart Device
Extensions para Visual Studio .NET con el fin de crear aplicaciones dirigidas a .NET Compact Framework.
Al igual que las interfaces de usuario tradicionales basadas en Windows, en el dispositivo móvil se debe
proporcionar control de excepciones para informar al usuario en caso de que se produzca una operación
errónea, y permitir a éste que pueda volver a intentar o cancelar la acción según sea necesario.
Smart Device Extensions for Microsoft Visual Studio® .NET no ofrece controles de validación de entrada,
por lo que debe implementar su propia lógica de validación del lado del cliente para garantizar que todas
las entradas de datos son válidas.
Si desea obtener más recursos para el desarrollo de la plataforma Pocket PC y .NET Compact Framework,
consulte la página de Smart Device Extensions (en inglés) en MSDN
(http://msdn.microsoft.com/vstudio/device/smartdev.asp).
Otro factor de forma móvil para clientes enriquecidos cuyo uso puede considerar es Tablet PC. Se trata de
un tipo de dispositivo portátil basado en Windows XP que admite la interacción del usuario a través de una
metáfora de "bolígrafo y tinta" en la que el usuario "dibuja" y "escribe" en la pantalla. Debido a que Tablet
PC se basa en Windows XP, se puede hacer uso completo de .NET Framework. También hay disponible

una API adicional para el control de las interacciones de "bolígrafo y tinta". Si desea obtener más
información sobre el diseño de aplicaciones para Tablet PC, consulte las recomendaciones de diseño de
Pocket PC (en inglés) en MSDN (http://msdn.microsoft.com/library/en-
us/tpcsdk10/html/whitepapers/designguide/tbconuxdgformfactorpenandink.asp).
Interfaces de usuario basadas en documentos
En lugar de crear una aplicación de escritorio personalizada basada en Windows para facilitar la
interacción del usuario, tiene más sentido en determinadas circunstancias permitir a los usuarios que
interactúen con el sistema a través de los documentos creados en herramientas de productividad comunes,
como Microsoft Word o Microsoft Excel. Los documentos son una metáfora común para el trabajo con
datos. En determinadas aplicaciones, se puede beneficiar del hecho de que los usuarios escriban o vean
datos en forma de documento en las herramientas que utilizan normalmente. Considere las siguientes
soluciones basadas en documentos:
• Informe de datos. La aplicación (basada en Windows o en el Web) puede ofrecer al usuario una
característica que le permita ver los datos de un documento del tipo adecuado; por ejemplo,
mostrando los datos de facturación como un documento de Word o una lista de precios como una
hoja de cálculos de Excel.
• Recopilación de datos. Puede permitir a los representantes de ventas que escriban la información
de venta para clientes telefónicos en hojas de cálculo de Excel para crear un documento de pedidos y,
a continuación, enviar el documento a su proceso empresarial.
Existen dos formas habituales de integrar un servicio de documentos en las aplicaciones, cada una de ellas
dividida en dos escenarios comunes: la recopilación de datos del usuario y el informe de los datos al
mismo.
Uso de documentos externos
Puede trabajar con documentos "externos", tratándolos como una entidad. En este tipo de escenarios, el
código funciona en un documento ajeno a la aplicación. Este enfoque presenta la ventaja de que el archivo
del documento se puede conservar tras una sesión específica. Este modelo resulta útil cuando se dispone
de zonas de "forma libre" en el documento que la aplicación no requiera pero que tal vez necesita
conservar. Por ejemplo, puede utilizar este modelo para permitir a los usuarios que escriban información
en un documento en un dispositivo móvil y se beneficien de las capacidades de ActiveSync de Pocket PC
para sincronizar los datos entre el documento de dicho dispositivo móvil y un documento mantenido en el
servidor. En este modelo de diseño, la interfaz de usuario realizará las siguientes funciones:
• Recopilación de datos. Un usuario determinado puede escribir información en un documento,
inicialmente un documento en blanco, o más frecuentemente, una plantilla predefinida que presenta
campos específicos.
El usuario envía a continuación el documento a una aplicación basada en Windows, o la carga en una
aplicación basada en el Web. La aplicación busca los datos y campos del documento a través del
modelo de objetos del mismo y realiza posteriormente las acciones necesarias.

Llegados a este punto, puede decidir conservar el documento tras el procesamiento o deshacerse de
él. Normalmente, los documentos se conservan para mantener un historial de seguimiento, o para
almacenar los datos adicionales que el usuario ha escrito en las zonas de forma libre.
• Informe de datos. En este caso, una interfaz de usuario basada en Windows o en el Web proporciona
una forma de generar un documento en el que se muestran datos determinados, como una factura de
venta. Normalmente, el código de informe toma datos del proceso de usuario saliente, proceso
empresarial y/o componentes lógicos de acceso a datos. Asimismo, el código llama a macros de la
aplicación del documento para insertar los datos y darles formato, o guarda un documento con el
formato adecuado y lo devuelve al usuario. Puede devolver el documento guardándolo en disco y
proporcionando un vínculo al mismo (necesitaría almacenar el documento en un almacén central en
baterías de servidores Web con equilibrio de carga), o bien, incluyéndolo como parte de la respuesta.
Al devolver documentos en aplicaciones basadas en el Web, es necesario decidir si mostrar el
documento en un explorador para que lo vea el usuario o presentar a éste una opción para guardar el
documento en disco. Esto se suele controlar definiendo el tipo MIME adecuado en la respuesta de una
página ASP.NET. En los entornos Web, debe seguir cuidadosamente las siguientes convenciones de
nombres de archivo para evitar que varios usuarios sobrescriban sus archivos correspondientes.
Uso de documentos internos
Si desea proporcionar una experiencia de usuario integrada dentro del documento, puede incrustar la
lógica de la aplicación en el propio documento. En este modelo de diseño, la interfaz de usuario realizará
las siguientes funciones:
• Recopilación de datos. Los usuarios pueden escribir datos en documentos con formularios
predefinidos y, a continuación, se pueden invocar macros específicas en la plantilla para recopilar los
datos adecuados e invocar a sus componentes empresariales o de proceso de usuario. Este enfoque
proporciona una experiencia de usuario más integrada, ya que el usuario sólo necesita hacer clic en
un botón personalizado u opción de menú en la aplicación host para realizar el trabajo, en lugar de
tener que enviar el documento completo.
• Informe de datos. Puede implementar entradas de menú y botones personalizados en los documentos
para recopilar datos determinados del servidor y posteriormente mostrarlos. También puede utilizar
tarjetas inteligentes para proporcionar funcionalidad de integración en línea enriquecida para todas
las herramientas de productividad de Microsoft Office. Por ejemplo, puede proporcionar una etiqueta
inteligente que permita a los usuarios visualizar la información completa de contacto de cliente de la
base de datos de CRM cuando un representante de ventas escriba el nombre del cliente en el
documento.
Independientemente de si trabaja con un documento externo o interno, debe proporcionar una lógica de
validación para garantizar que todas las entradas de usuario son válidas. Esto lo puede conseguir, en
parte, limitando los tipos de datos de campos, pero en la mayoría de los casos necesitará implementar
funcionalidad personalizada para comprobar la entrada del usuario y mostrar mensajes de error si se
detectan datos no válidos. Los documentos basados en Microsoft Office pueden incluir macros
personalizadas para ofrecer esta funcionalidad.

Si desea obtener más información sobre el modo de integrar una IU basada exclusivamente en Office en
sus procesos empresariales, consulte "Microsoft Office XP Resource Kit for BizTalk Server Version 2.0" (en
inglés) (http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-
files/027/001/743/msdncompositedoc.xml).
Si desea obtener más información sobre el uso de Office y .NET, consulte MSDN. Los siguientes dos
artículos le ayudarán a familiarizarse con el desarrollo de aplicaciones basadas en Office y .NET:
• "Introducing .NET to Office Developers" (en inglés)
us/dnofftalk/html/office10042001.asp)
• "Microsoft Office and .NET Interoperability" (en inglés)
us/dnofftalk/html/office11012001.asp)
Puede administrar flujos de trabajo basados en documentos beneficiándose de las ventajas que aportan
los servicios que proporciona Microsoft SharePoint Portal™. Este producto puede administrar el proceso de
usuario y proporcionar metadatos enriquecidos y capacidades de búsqueda.
Acceso a componentes lógicos de acceso a datos desde la interfaz de usuario
Las interfaces de usuario de determinadas aplicaciones necesitan procesar los datos disponibles como
consultas expuestas por los componentes lógicos de acceso a datos. Independientemente de si los
componentes de la interfaz de usuario invocan directamente a los componentes lógicos de acceso a datos,
se recomienda no mezclar la lógica de acceso a datos con la lógica de procesamiento empresarial.
El acceso directo a los componentes lógicos de acceso a datos desde la interfaz de usuario parece
contradecir el concepto de disposición en capas. No obstante, resulta útil en este caso considerar a la
aplicación como un servicio homogéneo; se llama a la aplicación y ésta decide cuáles son los componentes
internos más adecuados para responder a una solicitud determinada.
Se recomienda permitir a los componentes lógicos de acceso a datos el acceso directo a los componentes
de la interfaz de usuario cuando:
• Está dispuesto a relacionar estrechamente los métodos y esquemas de acceso a datos con la
semántica de la interfaz de usuario. Esta relación requiere el mantenimiento conjunto de los cambios
de la interfaz de usuario y de los esquemas.
• La implementación física coloca juntos a los componentes lógicos de acceso a datos y a los
componentes de interfaz de usuario, lo que permite obtener datos en formatos de secuencias (como
DataReader) de los componentes lógicos de acceso a datos, que se pueden enlazar directamente a la
salida de las interfaces de usuario ASP.NET para obtener un mayor rendimiento. Si implementa la
lógica de acceso a datos y de los procesos empresariales en servidores diferentes, no podrá
beneficiarse de esta capacidad. Desde el punto de vista del funcionamiento, permitir el acceso directo
a los componentes lógicos de acceso a datos para poder hacer uso de las capacidades de transmisión

conlleva la necesidad de proporcionar acceso a la base de datos en la que se distribuyen los
componentes lógicos de acceso a datos; incluido probablemente el acceso a través de puertos de
servidores de seguridad. Si desea obtener más información, consulte el capítulo 4: "Implementación
física y requisitos operativos".
Diseño de componentes de proceso de usuario
La interacción del usuario con la aplicación puede seguir un proceso predecible. Por ejemplo, puede que la
aplicación comercial requiera que los usuarios escriban los datos de los productos, vean el precio total,
escriban los detalles de pago y, finalmente, escriban la información relativa a la dirección del pedido. Este
proceso conlleva la visualización y aceptación de la entrada de un número de elementos de interfaz de
usuario, y el estado del proceso (los productos solicitados y los detalles de las tarjetas de crédito, entre
otros) se debe mantener en la transición de un paso a otro del proceso. Para facilitar la coordinación del
proceso de usuario y controlar el mantenimiento del estado requerido al visualizar varias páginas o
formularios de la interfaz de usuario, puede crear componentes de proceso de usuario.
Nota La implementación de una interacción con el usuario a través de componentes de proceso de
usuario no es una tarea sencilla. Antes de decidirse por este método, evalúe detenidamente si la
aplicación requiere o no el nivel de organización y abstracción que proporcionan este tipo de componentes.
Los componentes de proceso de usuario se implementan normalmente como clases .NET que exponen
métodos a los cuales pueden llamar las interfaces de usuario. Cada método encapsula la lógica necesaria
para realizar una acción específica en el proceso de usuario. La interfaz de usuario crea una instancia del
componente del proceso de usuario y la utiliza para efectuar la transición a través de los pasos del
proceso. Los nombres de los formularios particulares o de las páginas ASP.NET que se deben visualizar
para cada uno de los pasos del proceso se pueden insertar en el código del componente de proceso de
usuario (enlazándolo estrechamente por tanto a implementaciones específicas de la interfaz de usuario) o
se pueden recuperar de un almacén de metadatos, como un archivo de configuración (facilitando la
reutilización del componente de proceso de usuario por parte de varias implementaciones de interfaz de
usuario). El diseño de componentes de proceso de usuario para su uso por parte de varias interfaces da
lugar a una implementación más compleja, debido al aislamiento de los problemas específicos de los
dispositivos. No obstante, puede facilitar la distribución del trabajo de desarrollo de la interfaz de usuario
entre varios equipos, cada uno de ellos utilizando el mismo componente de proceso de usuario.
Los componentes de proceso de usuario coordinan la visualización de los elementos de la interfaz. Se
abstraen de la funcionalidad de procesamiento y adquisición de datos proporcionada por los componentes
de la interfaz de usuario. Debe diseñarlos con el concepto de globalización en mente, para permitir la
implementación de la localización en la interfaz. Por ejemplo, debe esforzarse en utilizar formatos de
datos neutrales con respecto a la cultura y utilizar formatos de cadena Unicode de forma interna para
facilitar el consumo de los componentes de proceso de usuario por parte de una interfaz de usuario
localizada.
El siguiente código muestra el aspecto de un componente de proceso de usuario para un proceso de
comprobación.

public class PurchaseUserProcess
{
public PurchaseUserProcess()
{
// crear un GUID para realizar un seguimiento de esta actividad
userActivityID = System.Guid.NewGuid();
}
private int customerID;
private DataSet orderData;
private DataSet paymentData;
private Guid userActivityID;
public bool webUI; // indicador para señalar que el IU del cliente es
un sitio
// Web (o no)
public void ShowOrder()
{
if(webUI)
{
// Código para mostrar la página de detalles del pedido
System.Web.HttpContext.Current.Response.Redirect

("http://www.myserver.com/OrderDetails.aspx");
}
else // debe ser una IU de Windows
{
// código para mostrar la ventana de detalles del pedido.
OrderDetails = new OrderDetailsForm();
OrderDetails.Show();
}
}
public void EnterPaymentDetails()
{
// aquí va el código para mostrar la página o ventana de detalles
de pago
}
public void PlaceOrder()
{
// aquí va el código para hacer el pedido
ShowConfirmation();
}
public void ShowConfirmation()
{
// aquí va el código para mostrar la página o ventana de
confirmación

}
public void Finish()
{
// aquí va el código para regresar a la página o ventana principal
}
public void SaveToDataBase()
{
// aquí va el código para guardar la información de pedido y de
pago de las variables
// privadas en una base de datos
}
public void ResumeCheckout(System.Guid ProcessID)
{
// aquí va el código para volver a cargar el estado del proceso
desde la base de datos
}
public void Validate()
{
// aquí debería colocar el código para asegurarse de que las
variables de
// instancia del proceso tienen la información adecuada para el
paso actual
}
}

La separación de la funcionalidad de interacción del usuario en componentes de interfaz y proceso de
usuario conlleva las siguientes ventajas:
• El estado de la interacción de usuario de ejecución larga se mantiene más fácilmente, lo que permite
el abandono y la reanudación de la interacción, probablemente incluso utilizando una interfaz de
usuario diferente. Por ejemplo, un cliente podría agregar varios elementos a una cesta de compra
utilizando la interfaz de usuario basada en el Web y, a continuación, llamar a un representante de
ventas para completar el pedido.
• Varias interfaces de usuario pueden utilizar el mismo proceso. Por ejemplo, en la aplicación comercial,
se puede utilizar el mismo proceso de usuario para agregar un producto a una cesta de compra tanto
desde la interfaz de usuario basada en el Web como desde la aplicación basada en Windows Forms.
El uso de un enfoque sin estructura para diseñar la lógica de la interfaz de usuario puede dar lugar a
situaciones no deseadas, debido al aumento del tamaño de la aplicación o la incorporación de nuevos
requisitos. Si necesita agregar una interfaz de usuario específica para un dispositivo determinado, tal vez
deba volver a diseñar el flujo de datos y la lógica de control.
La partición del flujo de interacción de usuario de las actividades de procesamiento y recolección de datos
puede aumentar la facilidad del mantenimiento de la aplicación y proporcionar un diseño limpio al que se
puedan agregar fácilmente características aparentemente complejas, como la compatibilidad con el
trabajo fuera de línea. En la figura 2.4 se muestra el modo en que la interfaz y el proceso de usuario se
pueden abstraer el uno del otro.
Figura 2.4. Interfaces de usuario y componentes de proceso de usuario
Los componentes de proceso de usuario ayudan a resolver los siguientes problemas de diseño de
interfaces de usuario:
• Control de actividades de usuarios concurrentes. Determinadas aplicaciones permiten a los
usuarios realizar varias tareas a la vez poniendo a su disposición más de un elemento de interfaz. Por
ejemplo, una aplicación basada en Windows puede mostrar varios formularios, o una aplicación Web
puede abrir una segunda ventana de exploración.

Los componentes de proceso de usuario simplifican la administración del estado de varios procesos
salientes encapsulando todo el estado necesario para el proceso en un solo componente. Puede
asignar cada elemento de interfaz a una instancia determinada del proceso de usuario incorporando
un identificador de procesos personalizado en el diseño.
• Uso de varios paneles para una actividad. Si utiliza varias ventanas o paneles en una actividad
de usuario determinada, es importante mantenerlos sincronizados. En una aplicación Web, una
interfaz de usuario normalmente muestra un conjunto de elementos en una misma página (que
puede incluir marcos) para una actividad de usuario dada. No obstante, en las aplicaciones de cliente
enriquecidas, puede disponer de varias ventanas no modales que afectan a un solo proceso. Por
ejemplo, puede disponer de una ventana flotante de selección de categorías de productos en la
aplicación que permita especificar una categoría determinada, los productos de la cual se mostrarán
en otra ventana.
Asimismo, los componentes de proceso de usuario facilitan la implementación de este tipo de interfaz
a través de la centralización del estado de todas las ventanas en una única ubicación. Puede
simplificar aún más la sincronización en varios elementos de la interfaz utilizando formatos de enlace
a datos para los datos de estado.
• Aislamiento de las actividades de usuario de ejecución larga del estado empresarial.
Determinados procesos de usuario se pueden poner en pausa y posteriormente reanudar. El estado
intermedio del proceso de usuario se debe almacenar por lo general en una ubicación distinta a la de
los datos empresariales de la aplicación. Por ejemplo, un usuario puede especificar cierta información
necesaria para realizar un pedido y, a continuación, reanudar el proceso de desprotección. Los datos
de pedido pendiente se deben mantener en una ubicación distinta a la de los datos de los pedidos
completados, lo que permite realizar operaciones empresariales con los datos de los pedidos
completados (por ejemplo, contar el número de pedidos realizados en el mes actual) sin tener que
implementar reglas complejas de filtrado para evitar el uso de pedidos no completados.
Las actividades de usuario, al igual que los procesos empresariales, pueden presentar un "tiempo de
espera" específico cuando es necesario cancelar la actividad y se deben llevar a cabo las acciones de
compensación adecuadas en el proceso empresarial.
Puede diseñar los componentes de proceso de usuario para que se puedan serializar, o almacenar su
estado en una ubicación distinta a la de los datos empresariales de la aplicación.
Separación de un proceso de usuario de la interfaz de usuario
Para separar un proceso de usuario de la interfaz de usuario:
1. Identifique el proceso o los procesos empresariales que el proceso de interfaz de usuario ayudará a
realizar. Identifique el modo en que el usuario ve este proceso como una tarea (normalmente lo
puede hacer consultando los diagramas de secuencia creados como parte del análisis de requisitos).
2. Identifique los datos que necesitan los procesos empresariales. El proceso de usuario necesitará ser
capaz de enviar datos cuando sea necesario.

3. Identifique el estado adicional que necesitará mantener a lo largo de la actividad del usuario para
ayudar al procesamiento y la captura de datos en la interfaz de usuario.
4. Diseñe el flujo visual del proceso de usuario y el modo en que cada elemento de la interfaz recibe o
da flujo de control.
Asimismo, necesitará implementar código para asignar una sesión de interfaz de usuario determinada al
proceso de usuario relacionado:
• Las páginas ASP.NET tendrán que obtener el proceso de usuario actual a través de una referencia del
objeto Session o utilizando el proceso desde otro medio de almacenamiento, como una base de datos.
Necesitará esta referencia en los controladores de eventos para los controles de la página Web.
• Las ventanas y controles necesitan mantener una referencia al componente de proceso de usuario
actual. Puede mantener esta referencia en una variable de miembro. Sin embargo, se recomienda
que no mantenga la referencia en una variable global, ya que, si lo hace, la composición de interfaces
de usuario pasará a ser una tarea bastante compleja a medida que aumenta el tamaño de la interfaz.
Funcionalidad de los componentes de proceso de usuario
Los componentes de proceso de usuario:
• Proporcionan un modo simple de combinar los elementos de la interfaz de usuario en los flujos de
interacción del usuario sin que sea necesario volver a desarrollar el flujo de datos ni la lógica de
control.
• Separan el flujo de la interacción del usuario conceptual de la implementación o dispositivo en el que
ocurre.
• Encapsulan el modo en que las excepciones pueden afectar al flujo de proceso de usuario.
• Realizan el seguimiento del estado actual de la interacción del usuario.
• No deben inicializar ni participar en transacciones. Mantienen los datos internos relacionados con la
lógica empresarial de la aplicación y su estado interno, manteniendo los datos del modo adecuado.
• Mantienen el estado empresarial interno, normalmente aferrándose a una o varias entidades
empresariales afectadas por la interacción del usuario. Puede mantener varias entidades en variables
privadas o en una matriz interna o tipo de colección adecuado. En el caso de las aplicaciones basadas
en ASP.NET, puede mantener las referencias a estos datos en el objeto Session, pero ello limitará la
vida útil del proceso de usuario.
• Pueden proporcionar una característica de tipo "guardar y continuar más adelante" por la cual se
puede reiniciar la interacción de un usuario en otra sesión. Puede implementar esta funcionalidad
guardando el estado interno del componente de proceso empresarial de forma persistente y
proporcionando al usuario el modo de continuar una actividad determinada en un momento posterior.
Puede crear un componente de utilidad de administración de tareas personalizado para controlar el
estado de activación actual del proceso. El estado del proceso de usuario se puede almacenar en una
de las siguientes ubicaciones:

Arquitectura aplicaciones .net

Arquitectura aplicaciones .net

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (13)

Similar a Arquitectura aplicaciones .net

Similar a Arquitectura aplicaciones .net (20)

Último

Último (20)

Arquitectura aplicaciones .net