Diseño de Aplicaciones - Diseño de Los Componentes de Una Aplicación o Servicio Cap II

Directivas de seguridad, administración operativa y comunicaciones http://msdn.microsoft.com/es-es/library/ms978348(printer).
aspx
©2009 Microsoft Corporation. All rights reserved.
Directivas de seguridad, administración operativa y comunicaciones

Publicado: 26 de junio de 2006
Patterns & Practices

Microsoft Corporation
Diciembre de 2002
http://msdn.microsoft.com/practices/ [ http://msdn.microsoft.com/practices/default.aspx ]
Resumen: en este artículo 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.
En el capítulo 1 se describe cómo una aplicación o un servicio se compone de varios componentes, así como
el modo en que cada uno de los cuales realiza una tarea diferente. Todas las soluciones de software contienen
tipos de componentes similares, independientemente de las necesidades empresariales que deban cubrir. Por
ejemplo, la mayoría de las aplicaciones contienen componentes que tienen acceso a datos, encapsulan reglas
empresariales y controlan la interactuación con el usuario, entre otros. La identificación de los tipos de
componentes que se encuentran normalmente en las soluciones de software distribuidas facilitará la
elaboración de un plano técnico para el diseño de aplicaciones o servicios.
Capítulo 2 de Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios. Comience por aquí [
http://msdn.microsoft.com/es-es/library/ms978340.aspx ] para obtener una visión general completa.
En esta página
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
Próximamente
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.
1 de 41 08/10/2009 05:29 p.m.

Directivas de seguridad, administración operativa y comunicaciones http://msdn.microsoft.com/es-es/library/ms978348(printer).aspx
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 interactuació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 interactuació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
interactuaciones 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 interactuació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
2 de 41 08/10/2009 05:29 p.m.

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". [ http://msdn.microsoft.com/es-es/library/ms978357.aspx ]
Principio de la página
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. Asimismo, 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
3 de 41 08/10/2009 05:29 p.m.

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 interactuació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 interactuaciones más complejas conllevan el diseño de
componentes de proceso de usuario que permiten organizar los elementos de la interfaz y controlar la
interactuación con el usuario. Los componentes de proceso de usuario resultan especialmente útiles cuando la
interactuació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
4 de 41 08/10/2009 05:29 p.m.

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 interactuació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
5 de 41 08/10/2009 05:29 p.m.

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 interactuació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
6 de 41 08/10/2009 05:29 p.m.

desconexión o fuera de línea, o interactuació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).
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 [ http://msdn.microsoft.com
/library/default.asp.aspx?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
7 de 41 08/10/2009 05:29 p.m.

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.
8 de 41 08/10/2009 05:29 p.m.

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 [
http://msdn.microsoft.com/library/default.asp.aspx?url=/nhp/default.asp?contentid=28000440 ] ) y el sitio
oficial de ASP.NET (en inglés) (http://asp.net [ http://asp.net/Default.aspx?tabid=1 ] ).
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 [ http://msdn.microsoft.com/library/default.asp.aspx?url=

/nhp/Default.asp?contentid=28001368 ] (en inglés)
9 de 41 08/10/2009 05:29 p.m.

Microsoft SharePoint Portal™ Server 2001 [ http://msdn.microsoft.com/library

/default.asp.aspx?url=/library/en-us/spssdk/html/_welcome_to_tahoe.asp ] (en inglés)
IBuySpy Portal [ http://msdn.microsoft.com/library/en-us/dnbda/html/bdasampibsport.asp ] (en

inglés)
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 interactuació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
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
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 interactuació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
10 de 41 08/10/2009 05:29 p.m.

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
Interfaces de usuario basadas en documentos
En lugar de crear una aplicación de escritorio personalizada basada en Windows para facilitar la interactuació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
11 de 41 08/10/2009 05:29 p.m.

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)
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) (http://msdn.microsoft.com/library

/library/default.asp.aspx?url=/library/en-us/dnofftalk/html/office10042001.asp ] )
"Microsoft Office and .NET Interoperability" (en inglés) (http://msdn.microsoft.com/library

/library/default.asp.aspx?url=/library/en-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
12 de 41 08/10/2009 05:29 p.m.

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 [
http://msdn.microsoft.com/es-es/library/ms978363.aspx ] ".
Diseño de componentes de proceso de usuario
La interactuació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 interactuació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();
13 de 41 08/10/2009 05:29 p.m.

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 interactuación del usuario en componentes de interfaz y proceso de

usuario conlleva las siguientes ventajas:
El estado de la interactuación de usuario de ejecución larga se mantiene más fácilmente, lo que

permite el abandono y la reanudación de la interactuació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 interactuació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.
14 de 41 08/10/2009 05:29 p.m.

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
15 de 41 08/10/2009 05:29 p.m.

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
interactuació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 interactuació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 interactuació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 interactuació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 interactuació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:
Si el proceso de usuario puede continuar desde otros dispositivos o equipos, deberá

almacenarlo de forma central en una ubicación como, por ejemplo, una base de
datos.
Si se encuentra en un entorno desconectado, el estado del proceso de usuario se

deberá almacenar de forma local en el dispositivo del usuario.
Si, por el contrario, el proceso de la interfaz de usuario se ejecuta en una batería de

servidores Web, deberá almacenar el estado requerido en una ubicación de servidor
central, de modo que se pueda continuar desde cualquiera de los servidores de la
batería.
16 de 41 08/10/2009 05:29 p.m.

Puede inicializar el estado interno llamando a un componente del proceso empresarial o a

componentes lógicos de acceso a datos.
No se implementan normalmente como componentes de Enterprise Services. La única razón para

hacerlo sería utilizar las capacidades de autorización basadas en funciones de Enterprise Services.
Se pueden inicializar por parte de un componente de utilidad personalizado que administra los
menús de la aplicación.
Diseño de interfaces de componentes de proceso de usuario
La interfaz de los componentes de proceso de usuario pueden exponer los siguientes tipos de funcionalidad,
como se muestra en la figura 2.5.
Figura 2.5. Diseño de componentes de proceso de usuario
"Acciones" de proceso de usuario (1). Se trata de la interfaz de acciones que suele activar un
cambio en el estado del proceso de usuario. Las acciones se implementan en los métodos de
componentes del proceso de usuario, como demuestran los métodos ShowOrder,
EnterPaymentDetails, PlaceOrder y Finish en el código de ejemplo mostrado anteriormente. Debe
intentar encapsular las llamadas a los componentes empresariales en estos métodos de acción
(6).
Métodos de acceso a estado (2). Puede obtener acceso al estado específico de la empresa y al
estado independiente de la misma del proceso de usuario utilizando propiedades Get y Set
detalladas que exponen un valor, o exponiendo un conjunto de entidades empresariales con las
que trata el proceso de usuario (5). Por ejemplo, en el código de ejemplo anterior, el estado del
proceso de usuario se puede recuperar a través de propiedades de conjuntos de datos públicas.
Eventos de cambio de estado (3). Estos eventos se activan cuando el estado específico o ajeno
a la empresa del proceso de usuario cambia. A veces será necesario implementar uno mismo
estas notificaciones de cambio. Sin embargo, en otros casos, puede almacenar los datos a través
de un mecanismo que realice esta tarea de forma intrínseca (por ejemplo, los conjuntos de datos
activan eventos siempre que sus datos cambian).
Funciones de control que permiten iniciar, poner en pausa, reiniciar y cancelar un

proceso de usuario determinado (4). Estas funciones se deben mantener de forma
independiente, pero se pueden mezclar con las acciones del proceso de usuario. Por ejemplo, el
código de ejemplo anterior contiene métodos SaveToDataBase y ResumeCheckout. Los métodos
de control podrían cargar los datos de referencia necesarios para la IU (como la información
necesaria para rellenar un cuadro combinado) desde los componentes lógicos de acceso a datos
(7) o delegar esta tarea al componente de la interfaz de usuario (formularios, controles y páginas
ASP.NET, entre otros) que necesita los datos.
Recomendaciones generales relativas a los componentes de proceso de usuario
17 de 41 08/10/2009 05:29 p.m.

Tenga en cuenta las siguientes recomendaciones al diseñar componentes de proceso de usuario:
Decida si necesita o no administrar los procesos de usuario como componentes independientes de

la implementación de la interfaz de usuario. Los procesos de usuario independientes son más
necesarios en aplicaciones con un gran número de cuadros de diálogo de interfaz de usuario, o en
las aplicaciones en las que los procesos de usuario pueden estar sujetos a personalización y se
pueden beneficiar de un enfoque de complementos.
Elija la ubicación en la que almacenar el estado del proceso de usuario:
Si el proceso se ejecuta de forma conectada, almacene el estado temporal de los

procesos de ejecución larga en una base de datos SQL Server central. En los
escenarios desconectados, sin embargo, almacénelo en archivos XML locales, en una
ubicación aislada o en bases de datos Microsoft SQL Server™ 2000 Desktop Engine
(MSDE) locales. En los dispositivos Pocket PC, puede almacenar el estado en una
base de datos SQL Server CE.
Si el proceso no es de ejecución larga y no es necesario recuperarlo en caso de que

ocurra algún problema, mantenga el estado en la memoria. En el caso de las
interfaces de usuario creadas para clientes enriquecidos, mantenga también el estado
en memoria. Para las aplicaciones Web, almacene el estado del proceso de usuario en
el objeto Session de ASP.NET. Si se encuentra en una batería de servidores Web, se
recomienda que almacene la sesión en un servidor de estado central o en una base
de datos SQL Server. ASP.NET limpiará la sesión almacenada en SQL Server para
evitar la aglomeración de datos de estado.
Diseñe los componentes de proceso de usuario de modo que se puedan serializar. De este modo,
facilitará la implementación de los esquemas de persistencia.
Incluya control de excepciones en los componentes de proceso de usuario y propague las

excepciones a la interfaz de usuario. Los componentes de interfaz de usuario deben detectar las
excepciones generadas por los componentes de proceso de usuario y se deben publicar como se
describe en el capítulo 3: Directivas de seguridad, administración operativa y comunicaciones [
http://msdn.microsoft.com/es-es/library/ms978357.aspx ] ".
Conectividad de red y aplicaciones fuera de línea
En un gran número de casos, la aplicación requiere compatibilidad con operaciones fuera de línea cuando la
conectividad de red no está disponible. Por ejemplo, numerosas aplicaciones móviles, incluidos los clientes
enriquecidos para los dispositivos Pocket PC o Table PC, deben ser capaces de funcionar cuando el usuario
está desconectado de la red corporativa. Las aplicaciones fuera de línea deben basarse en datos locales y en
el estado del proceso de usuario para desempeñar su función. Siga las directrices generales que se indican a
continuación al diseñar aplicaciones fuera de línea.
El estado en línea y fuera de línea se debe mostrar al usuario. Esto se suele hacer en barras de estado o de
título, o con guías visuales en torno a los elementos de la interfaz de usuario que requieren una conexión con
el servidor.
Desarrolle la mayor parte de la interfaz de usuario de la aplicación de modo que pueda volver a utilizarla, sin
que sea necesario realizar modificaciones, o muy pocas, para admitir escenarios fuera de línea. En estado
fuera de línea, la aplicación no dispondrá de:
Acceso a los datos en línea devueltos por los componentes lógicos de acceso a datos.
Capacidad para invocar procesos empresariales de forma sincrónica. Por tanto, la aplicación no
sabrá si la llamada se realizó correctamente ni será capaz de utilizar los datos devueltos.
Si la aplicación no implementa en los servidores una interfaz basada completamente en mensajes pero se
basa en la adquisición sincrónica de los datos y en el conocimiento de los resultados de los procesos
empresariales (como hacen la mayor parte de las aplicaciones actuales), se recomienda realizar lo siguiente
para proporcionar el efecto óptico de conectividad:
Implemente una caché local para los datos de referencia de sólo lectura relacionada con las
actividades del usuario. A continuación puede implementar un componente lógico de acceso a
datos fuera de línea que implemente exactamente las mismas consultas que los componentes
lógicos de acceso a datos del lado del servidor, pero que tenga acceso al almacenamiento local.
Puede implementar la caché local como una base de datos MSDE de escritorio. De este modo,
podrá volver a utilizar el diseño y la implementación de los principales esquemas SQL Server y
18 de 41 08/10/2009 05:29 p.m.

procedimientos almacenados. No obstante, MSDE afecta al estado global del equipo en el que se
encuentra instalado, y puede tener problemas para obtener acceso a él desde aplicaciones
configuradas para confianza moderada. En un gran número de escenarios, el uso de MSDE puede
sobrepasar los requisitos de persistencia de estado, por lo que puede resultar una mejor solución
almacenar los datos en un archivo XML o un conjunto de datos persistente.
Implemente un componente empresarial fuera de línea que presente la misma interfaz que los
componentes empresariales, pero tome los datos enviados y los coloque en un sistema de
mensajería de almacenamiento y reenvío confiable, como Message Queue Server. Puede que a
continuación este componente fuera de línea no devuelva ningún valor, o un valor predefinido, a
su llamador.
Implemente funcionalidad de IU que proporcione un modo de inspeccionar la "bandeja de salida"

de acciones empresariales y probablemente elimine los mensajes contenidos en la misma. Si
Message Queue Server se utiliza para poner en cola los mensajes fuera de línea, no será necesario
establecer los permisos correspondientes en la cola para realizar esta tarea desde la aplicación.
Diseñe las transacciones de la aplicación para que se acomode a las interactuaciones de IU

basadas en mensajes. Deberá prestar especial cuidado en administrar el bloqueo optimista y los
resultados de las transacciones en función de los datos de estado. Una técnica habitual para llevar
a cabo actualizaciones es enviar los datos antiguos y nuevos y permitir que el proceso
empresarial o componente lógico de acceso a datos relacionado resuelva los conflictos eventuales.
En el caso de los procesos empresariales, el envío puede incluir datos de referencia esenciales
que la lógica empresarial utiliza para decidir si se deja pasar o no a los datos. Por ejemplo, al
realizar un pedido puede incluir los precios de los productos junto con el Id. y la cantidad de los
mismos. Si desea obtener información más detallada sobre el bloqueo optimista, consulte "Diseño
de componentes de niveles y traspaso de los datos a través de éstos" en MSDN
(http://www.microsoft.com/spanish/msdn/articulos/archivo/221102/voices/BOAGag.asp) [
http://www.microsoft.com/spanish/msdn/articulos/archivo/221102/voices/BOAGag.asp ]
Permita que el usuario mantenga el estado de los procesos de usuario de la aplicación en el disco
y los reanude más adelante.
La llegada de los dispositivos móviles basados en redes IP, la evolución del estándar de seguridad
inalámbrica, el estándar 802.11, IPv6, Tablet PC y otras tecnologías, aumentará la popularidad de las redes
inalámbricas. El problema que presentan las redes inalámbricas es que, con la tecnológica actual, no pueden
garantizar la conectividad con un alto nivel de confianza en todas las zonas. Por ejemplo, la estructura de
construcción, la maquinaria cercana y otros factores pueden causar "zonas oscuras" permanentes o
temporales en la red. Si diseña una aplicación para utilizarla en un entorno inalámbrico, considere su diseño
como una aplicación fuera de línea basada en mensajes con el fin de evitar una experiencia llena de
excepciones y reintentos. Por ejemplo, puede diseñar una aplicación de modo que un usuario fuera de línea
pueda escribir datos a través de la interfaz conectada, y que los datos se puedan almacenar en una base de
datos local, o poner en cola y sincronizar más adelante, cuando el usuario se vuelva a conectar. SQL Server
admite la réplica, que se puede utilizar para automatizar la sincronización de datos de modo que queden
acoplados de forma flexible, lo que permite la descarga de éstos al dispositivo fuera de línea mientras está
conectado, la modificación de los mismos cuando está desconectado y su resincronización cuando se vuelve a
conectar. Microsoft Message Queue Server permite la encapsulación de los datos en un mensaje y la puesta
en cola de los mismos en el dispositivo desconectado para su envío a una cola del lado del servidor cuando se
encuentra conectado. A continuación, los componentes del servidor leerán el mensaje de la cola y lo
procesarán. El uso de colas locales o la réplica de SQL Server para controlar la comunicación de la entrada del
usuario con el servidor puede ayudar a mitigar los problemas de conectividad, incluso cuando la aplicación
está conectada de forma nominal. En los casos en los que sea necesario un enfoque de acoplamiento menos
flexible, se recomienda utilizar transacciones y un inicio de sesión personalizado para garantizar la integridad
de los datos.
Cuando la sincronización de los datos tiene lugar entre una aplicación desconectada (o de acoplamiento
flexible) y un servidor, debe tener en cuenta las siguientes consideraciones de seguridad:
Message Queue Server proporciona su propio modelo de autorización, basado en la autenticación

de Windows. Si la aplicación se basa en una autenticación administrada por aplicaciones
personalizadas, los componentes del lado del cliente deberán firmar los documentos enviados al
servidor.
El cliente no se puede suplantar en el servidor si los datos se envían a través de una cola.
Si utiliza la réplica de SQL Server, tal vez deba especificar una cuenta con permiso de acceso a
las bases de datos SQL Server del servidor. Al replicar desde SQL Server CE en un dispositivo
móvil, es necesario establecer una conexión segura al sitio de los Servicios de Internet
Information Server (IIS) que contiene el agente de servidor de SQL Server CE Server. Si desea
19 de 41 08/10/2009 05:29 p.m.

obtener más información sobre la configuración de la réplica de SQL Server, consulte la

documentación suministrada con SQL Server y SQL Server CE.
Si la comunicación de red tiene lugar a través de una conexión HTTP, utilice el nivel de socket
seguro (SSL) para garantizar la seguridad del canal.
Notificación a los usuarios y comunicación empresarial de proceso a usuario
La función de la aplicación puede ser notificar a los usuarios sobre eventos específicos. A medida que
aumentan las capacidades de comunicación de Internet, dispondrá de más opciones para notificar a los
usuarios. Las tecnologías habituales incluyen actualmente el correo electrónico, la mensajería instantánea, la
mensajería de teléfono móvil y la paginación, entre otros.
En la notificación instantánea pueden intervenir un gran número de tecnologías de notificación diferentes y el

uso de servicios de presencia para detectar el modo adecuado de ponerse en contacto con un usuario.
Microsoft Patterns & Practices ha lanzado al mercado una arquitectura de referencia que cubre este escenario.
Diseño de capas empresariales
La parte más importante de la aplicación es la funcionalidad que proporciona. Una aplicación realiza un
proceso empresarial que consta de una o varias tareas. En los casos más simples, cada tarea se puede
encapsular en un método de un componente .NET y llamar de forma sincrónica o asincrónica. Para los
procesos empresariales más complejos que requieren varios pasos y transacciones de ejecución larga, la
aplicación necesita disponer de un modo de organizar las tareas empresariales y almacenar el estado hasta
que el proceso se haya completado. En este tipo de escenario, puede utilizar BizTalk Server Orchestration
para definir el flujo de trabajo del proceso empresarial. El programa BizTalk Server que implementa el flujo de
trabajo puede utilizar a continuación la funcionalidad de mensajería de BizTalk Server o llamar a los
componentes empresariales .NET para llevar a cabo cada una de las tareas del modo requerido.
Puede diseñar la lógica en las capas empresariales para su uso directo por parte de componentes de
presentación o su encapsulación como servicio y llamada a través de una interfaz de servicios, que coordina la
conversación asincrónica con los llamadores del servicio e invoca el flujo de trabajo de BizTalk Server o los
componentes empresariales. La parte principal de la lógica empresarial se suele denominar lógica de dominio.
Los componentes empresariales también pueden realizar solicitudes de servicios externos, en cuyo caso tal
vez sea preciso implementar agentes de servicios para administrar la conversación requerida para la tarea
empresarial específica realizada por cada uno de los servicios que necesita utilizar.
En la figura 2.6 se muestran las capas empresariales de una aplicación.
Figura 2.6. Capas de componentes empresariales
20 de 41 08/10/2009 05:29 p.m.

Componentes y flujos de trabajo empresariales
Al implementar lógica empresarial, es necesario decidir si es preciso organizar o no el proceso empresarial, o

si será suficiente con disponer de un conjunto de componentes empresariales.
Se recomienda el uso de flujos de trabajo empresariales (implementados con BizTalk Orchestration) para:
Administrar un proceso que conlleve varios pasos y transacciones de ejecución larga.
Exponer una interfaz que implemente un proceso empresarial que habilite la aplicación para
establecer una conversación o un contrato con otros servicios.
Beneficiarse de la amplia gama de adaptadores y conectores de numerosas tecnologías

disponibles para BizTalk Server.
Puede implementar el proceso empresarial utilizando sólo componentes empresariales cuando:
No necesite mantener el estado de la conversación más allá de la actividad empresarial, y la

funcionalidad empresarial se pueda implementar como una única transacción atómica.
Necesite encapsular funcionalidad y lógica que se pueda volver a utilizar por parte de numerosos
procesos empresariales.
La lógica empresarial que se debe implementar necesita una gran cantidad de programación, o el
control detallado de las estructuras de datos y API.
Necesita disponer del control total de los datos y del flujo de lógica.
En el ejemplo comercial, el pedido conlleva varios pasos (la autorización de la tarjeta de crédito, el
procesamiento del pago y la organización de la entrega, entre otros), los cuales se deben realizar en una
secuencia concreta. El enfoque de diseño más adecuado para este tipo de proceso empresarial es crear
componentes empresariales para encapsular cada uno de los pasos individuales en el proceso y organizar
dichos componentes utilizando un flujo empresarial.
Diseño de componentes empresariales
Los componentes empresariales pueden ser la raíz de las transacciones atómicas. Éstos implementan las
reglas empresariales en diversos patrones y aceptan y devuelven estructuras de datos simples o complejas.
Los componentes empresariales deben exponer funcionalidad de modo que sea independiente de los
almacenes de datos y los servicios necesarios para realizar la tarea, y se deben componer de forma coherente
desde el punto de vista del significado y transaccional.
Normalmente, la lógica empresarial evoluciona y aumenta, proporcionando lógica y operaciones de mayor

nivel que encapsulan la lógica preexistente. En un gran número de casos, necesitará componer funcionalidad
empresarial preexistente con el fin de realizar la lógica empresarial requerida. Al componer lógica
empresarial, debe prestar especial atención a la evolución de las transacciones.
Si el proceso empresarial invocará a otros procesos empresariales en el contexto de una transacción atómica,
todos los procesos invocados deben garantizar que sus operaciones participan en la transacción existente de
modo que las operaciones se deshagan en caso de que la lógica empresarial que realiza las llamadas se
interrumpa. Un técnica muy segura es volver a intentar una operación atómica si ésta da error, sin miedo a
que los datos pierdan su coherencia. Considere el límite de una transacción determinada como un límite de
reintento. Las transacciones de los servidores que ejecutan Windows se pueden administrar utilizando el
Controlador de transacciones distribuidas (DTC), utilizado por .NET Enterprise Services (COM+). Para
administrar transacciones distribuidas en entornos heterogéneos, puede utilizar COM Transaction Integrator
(COMTI) y Host Integration Server 2000. Si desea obtener más información sobre COMTI y Host Integration
Server, consulte http://www.microsoft.com/hiserver [ http://www.microsoft.com/hiserver/default.mspx ] (en
inglés).
Si no puede implementar transacciones atómicas, necesitará ofrecer métodos y procesos de compensación.

Tenga en cuenta que una acción de compensación no devuelve necesariamente todos los datos de la
aplicación a su estado anterior, sino que restaura los datos empresariales a un estado coherente. Por ejemplo,
un proveedor puede exponer una interfaz de compra B2B (entre empresas) a sus socios. Una acción de
compensación para cancelar un pedido en proceso puede conllevar la imposición de una cantidad por la
cancelación de dicho pedido. En el caso de las transacciones y procesos de ejecución larga, la acción de
compensación puede variar en función del estado del flujo de trabajo, por lo que es necesario diseñar dichas
transacciones y procesos de forma adecuada para las distintas etapas del proceso.
Si desea obtener más información sobre el control de transacciones y el aislamiento de problemas de nivel,
consulte la sección relativa a transacciones en ".NET Data Access Architecture Guide" (en inglés) en MSDN
(http://msdn.microsoft.com/library/en-us/dnbda/html/daag.asp [ http://msdn.microsoft.com/library/en-us
/dnbda/html/daag.asp ] ).
21 de 41 08/10/2009 05:29 p.m.

En la siguiente lista se resumen las recomendaciones relativas al diseño de componentes empresariales:
Básese lo más que pueda en la comunicación basada en mensajes.
Asegúrese de que los procesos expuestos en las interfaces de servicios no se pueden alterar y
que, por tanto, el estado de la aplicación o el servicio no perderá su coherencia si se recibe el
mensaje dos veces.
Elija con cuidado los límites de la transacción de modo que se puedan realizar reintentos y
composiciones. Esto se aplica tanto a las transacciones atómicas como a las de ejecución larga.
Asimismo, debe considerar el uso de reintentos para sistemas basados en mensajes, sobre todo
al exponer la funcionalidad de la aplicación como un servicio.
Los componentes empresariales se deben poder ejecutar en el contexto de cualquier usuario de

servicio; no necesariamente suplantando a un usuario de una aplicación específica. Esto permite
su invocación con mecanismos que ni transmiten ni delegan la identidad del usuario.
Elija y mantenga un formato de datos coherente (como XML, conjunto de datos, etc.) para los
parámetros de entrada y los valores de devolución.
Defina los niveles de aislamiento de forma adecuada. Si desea obtener más información sobre el
control de transacciones y el aislamiento de problemas de nivel, consulte la sección relativa a
transacciones en ".NET Data Access Architecture Guide" (en inglés) en MSDN
(http://msdn.microsoft.com/library/en-us/dnbda/html/daag.asp [ http://msdn.microsoft.com
/library/en-us/dnbda/html/daag.asp ] ).
Implementación de componentes empresariales con .NET
Puede crear componentes que encapsulen la lógica empresarial utilizando .NET Framework. El código
administrado puede beneficiarse de Enterprise Services (COM+) para las transacciones distribuidas y otros
servicios habitualmente necesarios en las aplicaciones distribuidas.
Los componentes empresariales:
Son invocados por la capa de proceso de usuario, las interfaces de servicios y otros procesos
empresariales, normalmente con datos empresariales, expresados como una estructura compleja
de datos (un documento).
Son la raíz de las transacciones y, por tanto, deben votar en las transacciones en las que
participan.
Deben validar la entrada y la salida.
Pueden exponer operaciones de compensación para los procesos empresariales que proporcionan.
Pueden llamar a componentes lógicos de acceso a datos para recuperar y actualizar los datos de
la aplicación.
Pueden llamar a servicios externos a través de agentes de servicios.
Pueden llamar a otros componentes empresariales e inicializar flujos de trabajo empresariales.
Pueden enviar una excepción al llamador si se produce algún error al utilizar transacciones
atómicas.
Pueden utilizar características de Enterprise Services para inicializar y votar en transacciones

heterogéneas. Debe considerar el hecho de que las diferentes opciones transaccionales pueden
repercutir considerablemente en el rendimiento. No obstante, la administración de transacciones
no es un mecanismo o una variable de ajuste para mejorar el rendimiento de la aplicación. Si
desea ver comparaciones de rendimiento de diferentes enfoques transaccionales, consulte
"Control de transacciones: Comparación de rendimiento" en MSDN (http://www.microsoft.com
/spain/msdn/articulos/archivo/070602/voices/Bdadotnetarch13.asp [ http://www.microsoft.com
/spanish/msdn/articulos/archivo/070602/voices/Bdadotnetarch13.asp ] ). La configuración
transaccional puede ser:
Required. Utilice esta opción para aquellos componentes que puedan ser la raíz de
una transacción o que participarán en transacciones existentes.
22 de 41 08/10/2009 05:29 p.m.

Supported. Utilice esta opción para aquellos componentes que no requieren

necesariamente una transacción, pero que desea que participen en una transacción
existente, si es que hay una.
RequiresNew. Utilice esta opción si desea que el componente inicie una nueva
transacción independiente de las transacciones existentes.
NotSupported. Utilice esta opción si no desea que el componente participe en

transacciones.
Nota
El uso de las opciones RequiresNew y NotSupported afecta a la facilidad de

composición de la transacción. Por tanto, tenga en cuenta la repercusión que puede
tener la recuperación de una transacción primaria.
Los componentes empresariales son llamados por los siguientes clientes:
Interfaces de servicios
Componentes de proceso de usuario
Flujos de trabajo empresariales
Otros componentes empresariales
En la figura 2.7 se muestra un componente empresarial típico que interactúa con los componentes lógicos de
acceso a datos, las interfaces y los agentes de servicios y otros componentes empresariales.
Figura 2.7. Componentes empresariales
Observe los siguientes puntos en la figura 2.7:
1. Los componentes empresariales pueden ser invocados por los componentes de las capas de
presentación (normalmente los componentes de proceso de usuario) o por flujos de trabajo
empresariales (no se muestra).
2. Los componentes empresariales pueden ser invocados por interfaces de servicios (por ejemplo, un
servicio Web XML o una función de escucha de Message Queue Server).
3. Los componentes empresariales pueden llamar a componentes lógicos de acceso a datos para
recuperar y actualizar datos, y pueden invocar a otros componentes empresariales.
4. Los componentes empresariales también pueden invocar a agentes de servicios. Tenga especial
cuidado al diseñar la lógica de compensación en caso de que el servicio al que desea tener acceso no
esté disponible o lleve demasiado tiempo devolver una respuesta.
Nota
Las flechas que aparecen en la figura 2.7 representan el flujo de control, no el flujo de datos.
Cuándo utilizar servicios empresariales para los componentes empresariales
23 de 41 08/10/2009 05:29 p.m.

Enterprise Services (COM+) son una clara opción para constituir el entorno host para los componentes
empresariales. Enterprise Services ofrecen a los componentes seguridad basada en funciones, control de
transacciones heterogéneo, agrupación de objetos e interfaces basadas en mensajes a través de componentes
en cola (entre otros). Puede no utilizar Enterprise Services en una aplicación. Sin embargo, para llevar a cabo
operaciones más complejas que las realizadas en un único origen de datos, necesitará sus servicios, y el uso
del modelo que proporciona Enterprise Services en la etapa inicial ofrece una pauta de crecimiento más
adecuada para el sistema.
Determine en la fase inicial del proceso de diseño si utilizará o no Enterprise Services en la implementación
de los componentes empresariales, ya que posteriormente resultará más difícil agregar o quitar las
características de Enterprise Services, así como el código del componente una vez creado éste.
Tenga en cuenta las siguientes características de diseño al implementar componentes con Enterprise
Services:
Restricción de canales remotos. Sólo se admiten los canales HTTP y DCOM-RPC. Si desea
obtener más información, consulte la sección Diseño de la directiva de comunicaciones [
http://msdn.microsoft.com/es-es/library/ms978357.aspx ] del capítulo 3, "Directivas de
seguridad, administración operativa y comunicaciones".
Componentes de nombres seguros. Debe firmar estos componentes y todos los componentes
que éstos a su vez utilizan.
Distribución. Los componentes bien se registran automáticamente (en cuyo caso requerirán
derechos administrativos en tiempo de ejecución), o bien, necesitará realizar un paso de
implementación adicional. No obstante, la mayoría de los componentes del lado del servidor
requieren pasos de implementación adicionales (para registrar orígenes de registro de eventos,
crear colas de Message Queue Server, etc.).
Seguridad. Debe decidir si utilizar el modelo de funciones de Enterprise Services, basado en la

autenticación de Windows, o utilizar simplemente la seguridad basada en .NET.
Si desea obtener más información sobre Enterprise Services, consulte "Descripción de los Enterprise Services
(COM+) en .NET" en MSDN (http://www.microsoft.com/spain/msdn/articulos/archivo/190702/voices
/entserv.asp [ http://www.microsoft.com/spanish/msdn/articulos/archivo/190702/voices/entserv.asp ] ).
Patrones utilizados frecuentemente para los componentes empresariales
Independientemente de si los componentes empresariales se alojan en Enterprise Services, existe un gran

número de patrones comunes para implementar tareas empresariales en el código. Entre los patrones
utilizados más frecuentemente se incluyen:
Patrón de canalización. Las acciones y consultas se ejecutan en un componente de forma

secuencial.
Una canalización es una definición de pasos que se ejecutan para realizar una función empresarial
determinada. Todos los pasos se ejecutan de forma secuencial. Cada paso puede conllevar la
lectura y escritura de datos que conforman el "estado de canalización" y puede o no obtener
acceso a un servicio externo. Al invocar un servicio asincrónico como parte de un paso, una
canalización puede esperar hasta que se devuelva una respuesta (si es que se espera) o continuar
con el paso siguiente de la canalización si no se requiere la respuesta para continuar con el
procesamiento.
Utilice este patrón cuando:
Pueda especificar la secuencia de un conjunto conocido de pasos.
No necesite esperar una respuesta asincrónica en cada paso.
Desea que todos los componentes indirectos puedan inspeccionar y actuar en los
datos procedentes de la cadena ascendente (pero no al contrario).
Entre las ventajas derivadas del uso de este patrón se incluyen:
Resulta fácil de comprender e implementar.
Aplica un procesamiento secuencial.
Resulta fácil de ajustar en una transacción atómica.
24 de 41 08/10/2009 05:29 p.m.

Entre las desventajas derivadas del uso de este patrón se incluyen:
El patrón puede ser demasiado simple, sobre todo para la organización de los
servicios en los que es necesario dividir la ejecución de la lógica empresarial de
formas complejas.
No controla construcciones condicionales, bucles y otra lógica de control de flujo. La

adición de un paso repercute en el rendimiento de la ejecución de la canalización.
Este patrón se utiliza muy a menudo en aplicaciones basadas en Microsoft Commerce Server. Si
desea obtener más información sobre el uso de las canalizaciones con Commerce Server, consulte
"Pipeline Programming Concepts" (en inglés) en la documentación del SDK de Commerce Server
2000 en MSDN (http://msdn.microsoft.com/library/en-us/comsrv2k
/htm/cs_sp_pipelineobj_woce.asp [ http://msdn.microsoft.com/library/en-us/comsrv2k
/htm/cs_sp_pipelineobj_woce.asp ] ).
Patrón de eventos. Los eventos se activan en circunstancias empresariales determinadas, y en

respuesta a estos eventos se genera código.
Este patrón se utiliza si desea que tengan lugar un gran número de actividades, las cuales
reciban los mismos datos iniciales y no se puedan comunicar entre sí. Las actividades se pueden
ejecutar en paralelo o de forma secuencial. Puede que funcionen o no diferentes
implementaciones, en función de la información de filtrado. Si las implementaciones se han
definido para ejecutarse de forma secuencial, no se puede garantizar el pedido.
Utilice este patrón cuando:
Desee administrar implementaciones independientes y aisladas de una "función"

específica de forma independiente.
Las respuestas de una implementación no afectan al funcionamiento de otra

implementación.
Todas las implementaciones son de sólo escritura o de tipo "activar y olvidar", donde
la salida del proceso empresarial no está definida por ninguna de las
implementaciones, o sólo por una implementación empresarial específica.
Entre las ventajas derivadas del uso de este patrón se incluyen:
Se aumenta la facilidad de mantenimiento gracias a la independencia de los procesos

empresariales no relacionados.
Incentiva el procesamiento paralelo, lo que puede dar lugar a ventajas en cuanto a

rendimiento.
Resulta fácil de ajustar en una transacción atómica.
Funciona independientemente de si las implementaciones se realizan de forma

asincrónica o sincrónica, ya que no se espera respuesta.
Entre las desventajas derivadas del uso de este patrón se incluyen:
No permite crear respuestas complejas para la función empresarial.
Un componente no puede utilizar los datos o el estado de otro para realizar su tarea.
Enterprise Services proporcionan el servicio de eventos, que ofrece un buen punto de inicio para
la implementación del patrón de eventos. Si desea obtener más información sobre los eventos de
Enterprise Services, consulte "COM+ Events" (en inglés) en la documentación del SDK de COM+
en MSDN (http://msdn.microsoft.com/library/en-us/cossdk/htm/pgservices_events_2y9f.asp [
http://msdn.microsoft.com/library/en-us/cossdk/htm/pgservices_events_2y9f.asp ] ).
Implementación de flujos de trabajo empresariales con BizTalk Server
Cuando los procesos empresariales requieren varios pasos o transacciones de ejecución larga, es necesario
administrar el flujo de trabajo, controlando el estado de la conversación e intercambiando mensajes con
25 de 41 08/10/2009 05:29 p.m.

diversos servicios según sea necesario. BizTalk Server incluye servicios de organización que facilitan el ajuste
a estos retos.
Puede diseñar procesos empresariales utilizando los servicios de BizTalk Server Orchestration y crear
programas XLANG que implementen la funcionalidad empresarial. Los programas XLANG se crean
gráficamente utilizando el diseñador de BizTalk Server Orchestration y pueden utilizar BizTalk Messaging
Services, componentes .NET y COM, Message Queue Server o secuencia de comandos para realizar las tareas
empresariales. Estos programas se pueden utilizar para implementar transacciones de ejecución larga, y
mantienen automáticamente su estado en una base de datos SQL Server.
Puede utilizar BizTalk Server Orchestration para implementar la mayoría de los tipos de funcionalidad
empresarial. No obstante, resulta muy adecuado cuando el proceso empresarial conlleva proceso de flujo de
trabajo de ejecución larga en los que se intercambian documentos empresariales entre varios servicios. Los
documentos se pueden enviar a BizTalk Server mediante programación, o bien, se pueden enviar una carpeta
de un sistema de archivos supervisado o una cola de mensajes conocida como función de recepción. Las
funciones de recepción garantizan que los documentos enviados coinciden con la especificación definida para
documentos empresariales esperados, y si es así, consumen el documento y lo envían al canal de proceso
empresarial adecuado de BizTalk Server. Desde este punto de vista, una función de recepción se puede
considerar como una forma simple de interfaz de servicios.
Si desea ver un ejemplo detallado acerca de cómo implementar un proceso empresarial utilizando BizTalk
Server Orchestration y Visual Studio .NET, consulte "Building a Scalable Business Process Automation Engine
Using BizTalk Server 2002 and Visual Studio .NET" (en inglés) en MSDN (http://msdn.microsoft.com/library
/en-us/dnbiz2k2/html/BizTalkVSautoeng.asp [ http://msdn.microsoft.com/library/en-us/dnbiz2k2
/html/BizTalkVSautoeng.asp ] ).
Cuando el proceso empresarial conlleva interactuaciones con los sistemas existentes, como aplicaciones de
gran sistema, BizTalk Server puede utilizar adaptadores para integrarse con ellos. Si desea obtener más
información sobre la integración de BizTalk Server con sistemas existentes, consulte "Legacy File Integration
Using Microsoft BizTalk Server 2000" (en inglés) en MSDN (http://msdn.microsoft.com/library/en-us/dnbiz
/html/legacyfileint.asp [ http://msdn.microsoft.com/library/en-us/dnbiz/html/legacyfileint.asp ] ).
Implementación de BizTalk Server Orchestration
En la figura 2.8 se muestra la interactuación de un proceso empresarial organizado con las interfaces de
servicios, los agentes de servicios y los componentes empresariales.
Figura 2.8. Un proceso empresarial organizado
1. Los flujos de trabajo empresariales se pueden invocar desde otros servicios o desde los componente4s
de presentación (normalmente de componentes de proceso de usuario) utilizando la interfaz de
servicios.
2. Un flujo de trabajo empresarial invoca a otros servicios a través de un agente de servicios o

directamente a través de interfaces de servicios. Los mensajes salientes no tienen que coincidir
necesariamente con un mensaje entrante. Puede implementar interfaces y agentes de servicios en el
código o, si sólo requiere operaciones simples, puede utilizar la transformación de mensajes y las
características de función de BizTalk Server.
26 de 41 08/10/2009 05:29 p.m.

3. Los flujos de trabajo empresariales invocan a componentes empresariales. El flujo de trabajo

empresarial o los componentes que éste invoca pueden inicializar transacciones atómicas.
4. Los flujos de trabajo empresariales invocan a componentes lógicos de acceso a datos para realizar
actividades relacionadas con los datos.
5. Al diseñar flujos de trabajo empresariales, debe tener en cuenta los tiempos de respuesta prolongados
o las invocaciones a métodos sin respuesta. BizTalk Server permite automáticamente las
conversaciones de ejecución larga con servicios externos.
Los programas de BizTalk Server Orchestration se crean de forma gráfica utilizando el diseñador de BizTalk
Server Orchestration. En la figura 2.9 se muestra el aspecto de un flujo de organización de la figura anterior
procesado por el software de dibujo y diagrama de Microsoft Visio®. Observe la gran similitud existente entre
el diagrama conceptual de la figura 2.9 y el flujo que un analista o desarrollador empresarial necesita.
Figura 2.9. Flujo de organización en el diseñador de BizTalk Server Orchestration ( ver la imagen
grande )
A continuación el dibujo se compila en un programa XLANG, un archivo con formato XML que contiene las
instrucciones necesarias para que BizTalk Server realice las tareas requeridas en el proceso empresarial.
Una vez compilado, el programa se puede inicializar de una de las siguientes formas:
Se puede enviar mediante programación un mensaje de BizTalk Server a BizTalk Server o a través
de un sistema de archivos o función de recepción de Message Queue Server.
Se puede inicializar un programa mediante programación desde código basado en COM utilizando
el moniker sked.
Si desea obtener más información sobre BizTalk Server Orchestration, lea BizTalk Server: The Complete
Reference por David Lowe et al (publicado por Osborne/McGraw Hill) y "Designing BizTalk Orchestrations" en
la documentación de BizTalk Server 2000 (en inglés) (http://msdn.microsoft.com/library/en-us/biztalks
/htm/lat_sched_intro_xiju.asp [ http://msdn.microsoft.com/library/en-us/biztalks
/htm/lat_sched_intro_xiju.asp ] ).
Si desea obtener más información sobre los adaptadores de BizTalk:
http://www.microsoft.com/biztalk/evaluation/adapter/default.mspx [ http://www.microsoft.com/biztalk
/evaluation/adapter/default.mspx ]
Puede encontrar la guía del desarrollador de BizTalk Server Adapter en:
http://msdn.microsoft.com/biztalk/ [ http://msdn.microsoft.com/biztalk/default.aspx ]
Diseño de una interfaz de servicios
Si expone funcionalidad empresarial como un servicio, es necesario proporcionar un punto de entrada para
que llamen los clientes que abstraiga a la implementación interna. Asimismo, puede que también necesite
exponer funcionalidad similar a llamadores diferentes con requisitos de autenticación y contratos de nivel de
servicio (SLA) distintos. Puede proporcionar un punto de entrada al servicio creando una interfaz de servicios.
Una interfaz de servicios es una entidad de software implementada normalmente como una fachada que
controla los servicios de asignación y transformación para permitir la comunicación con un servicio y aplica un
proceso y una política de comunicación. Una interfaz de servicios expone métodos, a los que se puede llamar
de forma individual o en una secuencia específica para formar una conversación que implemente una tarea
empresarial. Por ejemplo, el servicio de tarjetas de crédito del escenario de la aplicación comercial podría
proporcionar un método denominado AuthorizeCard que comprueba los detalles de las tarjetas de crédito y un
segundo método llamado ProcessPayment que transfiere los fondos de la cuenta del titular de la tarjeta al
distribuidor. Estos pasos se realizarían en el secuencia adecuada para procesar el pago de un pedido.
Los requisitos de formato de comunicación, esquema de datos, seguridad y el proceso necesarios se

determinan como parte de un contrato publicado por el servicio. Este contrato proporciona la información que
27 de 41 08/10/2009 05:29 p.m.

necesitan los clientes para localizar y comunicarse con la interfaz de servicios.
Tenga en cuenta las siguientes recomendaciones al diseñar interfaces de servicios:
Considere una interfaz de servicios como un límite de confianza de su aplicación.
Si sus interfaces de servicios se exponen a organizaciones y consumidores externos o se hacen

públicas, se recomienda diseñarlas de modo que los cambios a la implementación interna no
requieran un cambio en la interfaz de usuarios.
Puede que sea necesario que clientes diferentes consuman de formas distintas la lógica
empresarial del servicio, por lo que tal vez sea preciso publicar varias interfaces de servicios para
la misma funcionalidad.
Las interfaces de servicios distintas pueden definir canales de comunicación, formatos de

mensajes, mecanismos de autenticación, acuerdos de nivel de servicio de rendimiento y
capacidades transaccionales diferentes. Los acuerdos de nivel de servicio habituales se definen a
tiempo para responder con una cantidad determinada de información.
Puede implementar las interfaces de servicios de varias formas, en función del modo en que desea exponer
las funcionalidades de la aplicación o servicio:
Para exponer la lógica empresarial como un servicio Web XML, puede utilizar las páginas de
servicios Web ASP.NET o exponer determinados componentes a través de .NET Remoting
utilizando SOAP y HTTP.
Para exponer la funcionalidad del servicio a clientes enviando mensajes Message Queue Server,
puede utilizar los desencadenadores de Message Queue Server o los componentes en cola de
Enterprise Services, o bien, puede escribir sus propios servicios de recepción de mensajes.
Si desea obtener más información, consulte la sección Diseño de la directiva de comunicaciones [

http://msdn.microsoft.com/es-es/library/ms978357.aspx ] del capítulo 3, "Directivas de seguridad,
administración operativa y comunicaciones".
Características de interfaces de usuario
Tenga en cuenta las siguientes características de diseño de las interfaces de servicios:
A veces la infraestructura .NET permite utilizar una interfaz de servicios transparente (por
ejemplo, puede exponer objetos de Enterprise Services como servicios Web en Windows .NET
Server) y otras puede necesitar agregar elementos específicos a la aplicación, como servicios Web
XML, flujos de trabajo de BizTalk Orchestration o puertos de mensajería. Considere la repercusión
del uso de interfaces de servicios transparentes, ya que pueden no proporcionar el nivel de
abstracción necesario para facilitar los cambios en la funcionalidad empresarial en una fecha
posterior sin que ello afecte a la interfaz de servicios. La implementación de fachadas conlleva un
costo de desarrollo, pero facilita el aislamiento de los cambios y el aumento de la facilidad del
mantenimiento de la aplicación.
Las interfaces de servicios pueden implementar almacenamiento de datos en caché, asignación y

transformación de esquemas y formatos simples; sin embargo, estas fachadas no deben
implementar la lógica empresarial.
La interfaz de servicios puede conllevar un transporte transaccional (por ejemplo, Message Queue
Server) o no transaccional (por ejemplo, servicios Web XML a través de HTTP), lo que repercute
en la estrategia de administración de transacciones y errores.
Se recomienda que diseñe las interfaces de servicios de modo que se obtenga el nivel máximo de
interoperabilidad con otras plataformas y servicios, basándose siempre que se pueda en los
estándares del sector para los sistemas de comunicación, seguridad y formatos, formatos de
mensaje estándar o simple (por ejemplo, esquemas XML simples para servicios Web XML) y
mecanismos de autenticación específica de no plataforma.
En determinadas ocasiones la interfaz de servicios dispondrá de su propia identidad de seguridad

y autenticará los mensajes entrantes pero no podrá suplantarlos. Tenga en cuenta el uso de este
enfoque al llamar a componentes empresariales distribuidos en un servidor distinto a la interfaz
de servicios.
28 de 41 08/10/2009 05:29 p.m.

Uso de fachadas empresariales con interfaces de servicios
El canal o mecanismo de comunicaciones que utilice para exponer la lógica empresarial como un servicio
puede tener una forma asociada de implementar el código de la interfaz de servicios. Por ejemplo, si decide
crear servicios Web, la mayor parte de la lógica de la interfaz de servicios residirá en el propio servicio Web,
concretamente los archivos asmx.cs. También podría exponer el servicio a través de Message Queue Server,
en cuyo caso pudría utilizar los componentes en cola de Enterprise Services, escuchas personalizadas o
desencadenantes de Message Queue Server para "activar" el componente que actúa como interfaz de
servicios.
Si pretende crear un sistema que se pueda invocar a través de mecanismos diferentes, debe agregar una
fachada entre la lógica empresarial y la interfaz de servicios. Al implementar esta fachada, puede consolidar
en una ubicación el código relacionado con las políticas (como la autorización, la auditoría y las validaciones,
entre otros) de modo que se pueda utilizar por parte de varias interfaces de servicios que traten con diversos
canales. Esta fachada ofrece una mayor facilidad de mantenimiento debido a que aísla los cambios en los
mecanismos de comunicación de la implementación de los componentes empresariales. A continuación el
código de la interfaz de servicios trata con los detalles del mecanismo o el canal de comunicación (por
ejemplo, analizando los encabezados SOAP del servicio Web u obteniendo información de los mensajes de
Message Queue Server) y define el contexto adecuado para la invocación del componente de fachada
empresarial. En la figura 2.10 se muestra una fachada empresarial que se utiliza de este modo.
Figura 2.10. Uso de una fachada empresarial con interfaces de servicios
En la figura 2.10 se muestra un ejemplo de cómo una fachada empresarial se utiliza con las interfaces de
servicios de un sistema determinado. IIS y ASP.NET reciben una llamada HTTP (1) e invoca a la interfaz de
servicios Web MyWebService.asmx (2). Esta interfaz de servicios inspecciona varios encabezados de mensajes
SOAP y define el objeto principal adecuado en función de la autenticación del servicio Web. A continuación
invoca a un componente de la fachada empresarial (3) que valida, autoriza y audita la llamada. La fachada
invoca posteriormente a un componente empresarial que realiza el trabajo empresarial (4). El sistema debe a
continuación admitir Message Queue Server, de modo que se crea una escucha personalizada (5) que
selecciona mensajes e invoca un componente de interfaz de servicios denominado MyMSMQWorker (6). Este
componente extrae los datos de las propiedades de los mensajes de Message Queue Server (como Body,
Label, etc.) y define el objeto principal adecuado en el subproceso en función de la firma de mensaje de
Message Queue Server. A continuación invoca a la fachada empresarial. La división del código de la fachada
empresarial de la interfaz de servicios, permitió que la aplicación pudiera agregar un mecanismo de
comunicación con un esfuerzo considerablemente menor.
Administración de transacciones en las interfaces de servicios
La interfaz de servicios deberá tratar con un canal que proporcione capacidades transaccionales (como
Message Queue Server) o no lo haga (como servicios Web XML). Es muy importante que diseñe los límites
transaccionales de modo que las operaciones se puedan volver a intentar en caso de error. Para ello,
asegúrese de que todos los recursos que utilizan son transaccionales, marque su componente raíz como
"requiere transacción" y todos los subcomponentes como "requiere transacción" o "es compatible con las
transacciones".
Con los mecanismos de mensajería transaccionales, la interfaz de servicios comienza la transacción en primer
lugar y, a continuación, selecciona el mensaje. Si la transacción se deshace, el mensaje no se recibe
automáticamente y se vuelve a poner en la cola para un nuevo intento. Al utilizar Message Queue Server, los
componentes en cola de Enterprise Services o los desencadenantes de Message Queue Server, puede definir
una operación de tipo "poner en cola y recibir mensaje" como transaccional para conseguir este objetivo de
forma automática.
Si utiliza un mecanismo de mensajería no transaccional (como los servicios Web XML), necesitará llamar a la
raíz de la transacción desde el código de la interfaz de servicios. En caso de error, puede diseñar el código de
la interfaz para volver a intentar la operación o devolver una excepción adecuada al llamador o presentar los
datos que representan un error.
29 de 41 08/10/2009 05:29 p.m.

Representación de datos y pasarlos a través de niveles
Cuando los componentes lógicos de acceso a datos devuelven datos, pueden hacerlo en varios formatos. Los
formatos pueden variar desde un formato centrado en datos (por ejemplo, una cadena XML) hasta un formato
más orientado a objetos (por ejemplo, un componente personalizado que encapsula una instancia de una
entidad empresarial). Formatos de devolución de datos frecuentes son:
XML
DataReader
Conjunto de datos
Conjunto de datos con tipo
Objeto personalizado con propiedades que asignan a campos de datos y métodos que realizan
modificaciones de datos a través de componente lógicos de acceso a datos.
Si desea obtener más información sobre los distintos tipos de formatos de datos disponibles para el diseño de
aplicaciones, consulte "Diseño de componentes de niveles y traspaso de los datos a través de éstos [
http://www.microsoft.com/spanish/msdn/articulos/archivo/221102/voices/BOAGag.asp ] " en MSDN
El formato de datos que elija dependerá del modo en que quiera trabajar con los mismos. Se recomienda que
evite los diseños que requieran la transferencia de datos en un formato orientado a objetos personalizado, ya
que ello requiere la implementación de serialización personalizada y puede repercutir negativamente en el
rendimiento. Generalmente, debería utilizar un formato más centrado en datos, como conjunto de datos, para
pasar los datos de los componentes lógicos de acceso a datos a las capas empresariales y, a continuación,
utilizarlos para hacer uso de una entidad empresarial personalizada si desea trabajar con los datos de un
modo orientado a objetos. En un gran número de casos, sin embargo, resultará más fácil trabajar sólo con los
datos empresariales contenidos en un conjunto de datos.
Representación de datos con componentes de entidades empresariales personalizadas
En la mayoría de los casos, se recomienda que trabaje directamente con datos, utilizando los conjuntos de
datos ADO.NET o documentos XML. Esto permite también pasar los datos estructurados entre las distintas
capas de la aplicación sin tener que escribir código personalizado. No obstante, si desea encapsular todos los
detalles del uso de un formato en particular o si desea agregar comportamientos a los datos, tal vez deba
desarrollar componentes personalizados. De este modo, obtendrá control total sobre lo que los componentes
de la aplicación pueden hacer con los datos, permitiéndole abstraer formatos internos de los esquemas de
datos utilizados por la aplicación, así como agregar comportamiento a los datos. En esta guía se hace
referencia a los componentes que se utilizan para representar datos como entidades empresariales.
Por ejemplo, el proceso de pedido descrito anteriormente en esta guía podría utilizar un objeto Order, que
presenta un objeto Customer asociado, y una colección de objetos LineItem. Estos componentes forman parte
de las capas empresariales de la aplicación y otros componentes empresariales o de representación pueden
consumirlo.
Los componentes de entidad contienen datos de instantánea. Se trata de una caché de información local
efectiva, por lo que la coherencia de los datos sólo se puede garantizar si se leen en el contexto de una
transacción activa. Se recomienda no asignar una entidad empresarial a cada una de las tablas de la base de
datos; normalmente una entidad empresarial dispondrá de un esquema que es una desnormalización de
esquemas subyacentes. Tenga en cuenta que la entidad puede representar datos agregados de numerosos
orígenes.
Debido a que almacena los valores de los datos y los expone a través de sus propiedades, el componente
proporciona acceso programático con estado a los datos empresariales y la funcionalidad relacionada. Evite el
diseño de los componentes de entidad empresarial de modo que se obtenga acceso al almacén de datos cada
vez que una propiedad cambia y, e n su lugar, proporcione un método Update que propague todos los
cambios locales de nuevo a la base de datos. Los componentes de entidad empresarial no deben tener acceso
directo a la base de datos, pero deben utilizar componentes lógicos de acceso a datos para realizar las tareas
relacionadas con datos a medida que se invocan sus métodos. Las entidades empresariales no deben
inicializar ningún tipo de transacciones ni utilizar API de acceso a datos; son meramente una representación
de datos, potencialmente con comportamiento. Debido a que las entidades se pueden invocar desde
componentes empresariales e interfaces de usuario, deberían permitir el flujo de transacciones de forma
transparente y no deberían votar en transacciones salientes.
Es una buena idea diseñar componentes de entidad empresarial serializables, permitiéndole almacenar el
estado actual (por ejemplo, para almacenar en un disco local si se trabaja fuera de línea o en un mensaje de
Message Queue Server).
Los componentes de entidad empresarial simplifican la transición entre la programación orientada a objetos y
los modelos de desarrollo basados en documentos. El diseño orientado a objetos es habitual en entornos con
estado, como el diseño de interfaz de usuario, mientras que la funcionalidad y las transacciones empresariales
se pueden expresar normalmente de forma más clara en términos de intercambios de documentos.
30 de 41 08/10/2009 05:29 p.m.

Nota
Los componentes de entidad empresarial personalizados no son una parte obligatoria de todas las
aplicaciones. Un gran número de soluciones (sobre todo las aplicaciones basadas en ASP.NET y los
componentes empresariales) no utilizan representaciones personalizadas de entidades empresariales, sino
que en su lugar utilizan conjuntos de datos o documentos XML, ya que proporcionan toda la información
necesaria y el modelo de desarrollo se basa más en tareas y documentos que el orientado a objetos.
Diseño de interfaces de componentes de entidad empresarial
Los componentes de entidad empresarial exponen:
Descriptores de acceso a propiedades (funciones Get y Set) para los atributos de la entidad.
Descriptores de acceso a colecciones para subcolecciones de datos relacionados. (Las colecciones

no dan a lugar necesariamente a colecciones de entidades empresariales, por lo que puede
diseñar la entidad de servicio para exponer directamente conjuntos de datos o tablas de datos no
relacionados con la transversal de modelo de objetos).
Las funciones y propiedades de control que se utilizan normalmente en la administración de

entidades, por ejemplo, Load, Save, IsDirty y Validate.
Métodos de acceso a los metadatos de la entidad, que puede resultar útil para aumentar la
facilidad del mantenimiento de la interfaz de usuario.
Eventos para señalar los cambios en los datos subyacentes.
Métodos para realizar tareas empresariales u obtener datos para consultas complejas. Estos
métodos pueden actuar sólo en los datos locales (por ejemplo, Order.GetTotalCost) ni en los
componentes o procesos empresariales (por ejemplo, Order.Place).
Métodos e interfaces necesarios para el enlace a datos.
Entre los clientes de los componentes de entidad empresarial se incluyen:
Componentes de interactuación de usuario para clientes enriquecidos. Estos componentes se

pueden enlazar a los datos de las entidades empresariales o los datos expuestos por las consultas
expuestas por el componente. Las funciones de control de IU pueden definir y obtener
propiedades de entidades empresariales para la entrada y visualización de datos.
Componentes de proceso de usuario. Los componentes de proceso de usuario pueden mantener

una o varias entidades empresariales como parte de su estado interno específico de la aplicación.
Componentes empresariales. Los componentes empresariales pueden pasar una entidad

empresarial como un parámetro a un método de componente lógico de acceso a datos (por
ejemplo, se podría pasar un objeto Order a un método InsertOrder en un componente lógico de
acceso a datos).Asimismo, los componentes empresariales pueden utilizar entidades
empresariales para obtener acceso al comportamiento de datos (por ejemplo, llamando a un
método Place del objeto Order, que a su vez pasa los datos de pedido a un componente lógico de
acceso a datos), pero este enfoque es menos habitual que pasar directamente la entidad
empresarial a un método de componente lógico de acceso a datos porque mezcla un modelo
funcional orientado a documentos con un modelo basado en objetos.
Recomendaciones relativas al diseño de entidades empresariales
Estas recomendaciones le ayudarán a implementar el mecanismo adecuado para la representación de datos:
Considere cuidadosamente si necesita codificación de entidades personalizadas o si otras

representaciones de datos se ajustan a sus requisitos. La codificación de entidades personalizadas
es una tarea compleja cuyo costo de desarrollo aumenta con el número de características que
proporciona. Las entidades personalizadas se suelen implementar para aplicaciones que necesitan
exponer una macro personalizada o un modelo de objetos de secuencias de comandos fácil de
utilizar para el desarrollador para personalización.
Implemente entidades empresariales derivándolas de una clase base que proporciona

funcionalidad repetitiva y encapsula tareas habituales.
31 de 41 08/10/2009 05:29 p.m.

Básese en el mantenimiento de conjuntos de datos internos o documentos XML para datos

complejos en lugar de colecciones y estructuras internas, entre otros.
Implemente un conjunto habitual de interfaces en las entidades empresariales que exponen

conjuntos comunes de funcionalidad:
Métodos y propiedades de control, como Save, Load, Delete, IsDirty y Validate.
Métodos de metadatos, como getAttributesMetadata, getChildDatasetsMetadata y

getRelatedEntitiesMetadata, que resultan especialmente útiles para el diseño de
interfaces de usuario.
Aísle las reglas de validación como metadatos, por ejemplo, exponiendo esquemas XSD (lenguaje
de definición de esquemas XML). Asegúrese, sin embargo, de que los llamadores externos no
pueden modificar estas reglas de validación.
Las entidades empresariales deberían validar los datos que encapsulan a través de la aplicación
de reglas de validación continuas y a un momento dado.
Implemente una aplicación implícita de relaciones entre entidades basada en los esquemas de
datos y las reglas empresariales en torno a los datos. Por ejemplo, un objeto Order podría
disponer de un número máximo de referencias LineItem.
Diseñe entidades empresariales para que se basen en componentes lógicos de acceso a datos
para la interactuación con las bases de datos. De este modo, podrá implementar todas las
políticas de acceso a datos y la lógica empresarial relacionada en una ubicación. Si las entidades
empresariales tienen acceso directo a bases de datos SQL Server, será indicio de que las
aplicaciones implementadas a los clientes que utilizan entidades empresariales necesitarán
conectividad SQL y permisos de conexión.
Si desea obtener recomendaciones de diseño detalladas y código de ejemplo que le ayudará a desarrollar los
componentes de las entidades empresariales, consulte "Diseño de componentes de niveles y traspaso de los
datos a través de éstos [ http://www.microsoft.com/spanish/msdn/articulos/archivo/221102/voices
/BOAGag.asp ] " en MSDN
Diseño de capas de datos
Casi todas las aplicaciones y servicios necesitan almacenar y obtener acceso a un determinado tipo de datos.
Por ejemplo, la aplicación comercial descrita en esta guía necesaria almacenar datos de productos, clientes y
pedidos.
Al trabajar con datos debe determinar:
El almacén de datos que utiliza.
El diseño de los componentes utilizados para obtener acceso al almacén de datos.
El formato de los datos pasados entre componentes y el modelo de programación necesario para
ello
La aplicación o servicio puede disponer de uno o varios orígenes de datos, los cuales pueden ser de tipos
diferentes. La lógica utilizada para obtener acceso a los datos de un origen de datos se encapsulará en
componentes lógicos de acceso a datos que proporcionan los métodos necesarios para la consulta y
actualización de datos. Los datos con los que la lógica de la aplicación debe trabajar están relacionados con
entidades del mundo empresarial que forman parte de la empresa. En determinados escenarios, puede
disponer de componentes personalizados que representan estas entidades, mientras que en otros puede
decidir trabajar con datos utilizando directamente conjuntos de datos ADO.NET o documentos XML.
En la figura 2.11 se muestra cómo la capa de datos lógicos de una aplicación consta de uno o varios
almacenes de datos y describe una capa de componentes lógicos de acceso a datos utilizados para recuperar
y manipular los datos en dichos almacenes.
32 de 41 08/10/2009 05:29 p.m.

Figura 2.11. Componentes de datos
La mayoría de las aplicaciones utilizan una base de datos relacional como almacén principal de los datos de la
aplicación. También se puede utilizar el almacén de Web Microsoft Exchange Server, bases de datos
heredadas, el sistema de archivos o servicios de administración de documentos.
Cuando la aplicación recupera datos de la base de datos, puede hacerlo utilizando un formato de conjunto de
datos DataReader. A continuación los datos se transfieren entre las capas y los distintos niveles de la
aplicación y, finalmente, uno de los componentes los utilizará. Tal vez desee utilizar formatos de datos
diferentes para recuperar, pasar y utilizar datos; por ejemplo, puede utilizar los datos de un conjunto de
datos para llenar las propiedades de un objeto de entidad personalizado. No obstante, debería intentar
mantener una coherencia en cuanto al tipo de formato utilizado, ya que mejorará probablemente el
rendimiento y la facilidad de mantenimiento de la aplicación para presentar sólo un conjunto limitado de
formatos, evitando así la necesidad de capas de traducción adicionales y de familiarizarse con API diferentes.
En las siguientes secciones se describe la elección de almacenes de datos, el diseño de los componentes
lógicos de acceso a datos y las distintas posibilidades disponibles de representación de datos.
Almacenes de datos
Entre los tipos de almacenes habituales se encuentran:
Bases de datos relacionales. Las bases de datos relacionales, como las bases de datos SQL
Server, proporcionan funcionalidad de administración de un gran volumen de datos
transaccionales de alto rendimiento con capacidades de seguridad, operaciones y transformación
de datos. Las bases de datos relacionales también alojan instrucciones y funciones complejas de
lógica de datos en forma de almacenamientos almacenados que se pueden utilizar como un
entorno eficaz para los procesos empresariales con un gran volumen de datos. SQL Server
también proporciona una versión de escritorio tipo Palm que permite utilizar implementaciones
transparentes para los componentes lógicos de acceso a datos. El diseño de bases de datos está
más allá del alcance de esta guía. Si desea obtener más información sobre el diseño de bases de
datos relacionales, consulte "Database Design Considerations" (en inglés) en el SDK de SQL
Server 2000 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/createdb
/cm_8_des_02_62ur.asp [ http://msdn.microsoft.com/library/default.asp.aspx?url=/library
/en-us/createdb/cm_8_des_02_62ur.asp ] ).
Bases de datos de mensajería. Puede almacenar datos en el almacén Web de Exchange Server,
lo que resulta especialmente útil si la aplicación está centrada en el grupo, el trabajo en grupo o
mensajes y no desea basarse en otros almacenes de datos que pueden necesitar que se
administren de forma independiente. Sin embargo, los almacenes de datos de mensajes suelen
presentar menores capacidades de rendimiento, escalabilidad, disponibilidad y administración
33 de 41 08/10/2009 05:29 p.m.

que los sistemas de administración de bases de datos relacionales completas (RDBMS) y, por
tanto, es relativamente no habitual que las aplicaciones que utilicen el almacén de datos
proporcionado por un producto de mensajería. Si desea obtener más información sobre el
desarrollo de un almacén de datos basado en Exchange Server, consulte "Developing Web
Storage System Applications" (en inglés) en MSDN (http://msdn2.microsoft.com/library
/ms998679.aspx).
Sistema de archivos. Puede decidir almacenar los datos en sus propios archivos en el sistema
de archivos. Estos archivos pueden presentar su propio formato o el formato XML con un esquema
definido para los propósitos de la aplicación.
Hay un gran número de otros almacenes (como bases de datos XML, servicios de procesamiento analítico en
línea y bases de datos de almacenamiento de datos, entre otros) pero no son el objeto de análisis de esta
guía.
Componentes lógicos de acceso a datos
Independientemente del almacén de datos utilizado, la aplicación o el servicio utilizarán componentes lógicos
de acceso a datos para obtener acceso a los datos. Estos componentes abstraen la semántica del almacén de
datos subyacente y la tecnología de acceso a datos (como ADO.NET) y proporcionan una interfaz simple de
programación para la recuperación y realización de operaciones con datos.
Los componentes lógicos de acceso a datos suelen implementar un patrón de diseño sin estado que separa el
procesamiento empresarial de la lógica de acceso a datos. Cada uno de estos componentes suele proporcionar
métodos para realizar operaciones Create, Read, Update y Delete (CRUD) relacionadas con una entidad
empresarial determinada de la aplicación (por ejemplo, Order). Los procesos empresariales pueden utilizar
estos métodos. La interfaz de usuario pueden utilizar las consultas específicas para procesar los datos de
referencia (como una lista de tipos de tarjetas de crédito válidos).
Cuando la aplicación contiene varios componentes lógicos de acceso a datos, puede resultar útil utilizar un
componente de ayuda de acceso a datos genéricos para administrar las conexiones de las bases de datos,
ejecutar comandos y almacenar parámetros en caché, entre otros. Los componentes lógicos de acceso a datos
proporcionan la lógica necesaria para obtener acceso a datos empresariales específicos, mientras que el
componente de ayuda para el acceso a datos centraliza el desarrollo de API de acceso a datos y la
configuración de la conexión a éstos, permitiendo de esta forma la reducción de código duplicado. Un
componente de ayuda de acceso a datos bien diseñado no debe repercutir negativamente en el rendimiento y
proporciona una ubicación central para el ajuste y optimización del acceso a datos. Microsoft proporciona Data
Access Application Block para .NET (http://msdn2.microsoft.com/library/ms954827.aspx (en inglés)), que se
puede utilizar como un componente de ayuda de acceso a datos genéricos en la aplicación al utilizar bases de
datos SQL Server.
En la figura 2.12 se muestra el uso de componentes lógicos de acceso a datos para obtener acceso a datos.
Figura 2.12. Componentes lógicos de acceso a datos
1. Los componentes lógicos de acceso a datos exponen métodos para insertar, eliminar, actualizar y
recuperar datos, incluyendo la provisión de funcionalidad de paginación al recuperar grandes
cantidades de datos.
2. Puede utilizar un componente de ayuda de acceso a datos para centralizar la administración de la

conexión y todo el código relacionado con un origen de datos específico.
34 de 41 08/10/2009 05:29 p.m.

3. Se recomienda implementar las consultas y operaciones de datos como procedimientos almacenados

(si es compatible con el origen de datos) para mejorar el rendimiento y la facilidad de mantenimiento.
Nota
El uso de componentes lógicos de acceso a datos se recomienda para todas las aplicaciones que requieren
obtener acceso a datos empresariales (como productos y pedidos, entre otros). No obstante, otros productos
y tecnologías pueden utilizar bases de datos para almacenar sus propios datos operacionales, sin tener que
hacer uso de este tipo de componentes.
Los componentes lógicos de acceso a datos proporcionan acceso simple a funcionalidad de bases de datos
(consultas y operaciones de datos), devolviendo estructuras de datos simples y complejas. Ocultan las
idiosincrasias de la invocación y el formato del almacén de datos de los componentes empresariales y las
interfaces de usuario que las consumen. La implementación de una lógica propia de acceso a datos en los
componentes lógicos de acceso a datos permite encapsular toda la lógica de acceso a datos de la aplicación
completa en una única ubicación central, lo que facilita el mantenimiento y la extensibilidad de la aplicación.
Se recomienda que diseñe cada uno de los componentes lógicos de acceso a datos para trabajar con un único
almacén de datos. (Esto significa que los componentes no realizan consultas ni agregan datos de un gran
número de orígenes; esta función la realizan los componentes empresariales).
Al utilizar transacciones heterogéneas, los componentes lógicos de acceso a datos deben participar en ellas,
aunque constituir la raíz de las mismas. Resulta más adecuado que un componente empresarial desempeñe
esta función y que uno o varios componentes lógicos se utilicen para realizar las actualizaciones de la base de
datos.
Funcionalidad de los componentes lógicos de acceso a datos
Cuando se llaman, los componentes lógicos de acceso a datos realizan lo siguiente:
Llevan a cabo asignaciones y transformaciones simples de argumentos de entrada y salida. De

este modo, se abstrae la lógica empresarial de los esquemas de la base de datos y las formas de
procedimientos almacenados.
Obtienen acceso de un único origen. De este modo, aumenta la facilidad del mantenimiento
desplazando toda la funcionalidad de agregación de datos a los componentes empresariales,
donde los datos se pueden agregar en función de la operación empresarial específica que se está
realizando.
Actúan en una tabla principal y realizan operaciones en tablas relacionadas. (Los componentes
lógicos de acceso a datos no tienen por qué encapsular necesariamente operaciones sólo en una
tabla de un origen de datos subyacente.) De este modo, se aumenta la facilidad de
mantenimiento de la aplicación.
De forma opcional, pueden realizar las siguientes tareas:
Utilizan un componente de utilidad personalizado para administrar y encapsular esquemas de

bloqueo optimistas.
Utilizan un componente de utilidad personalizado para implementar una estrategia de

almacenamiento de datos en caché para los resultados de consultas no transaccionales.
Implementan el enrutamiento dinámico de datos de sistemas de gran escala que proporcionan

escalabilidad a través de la distribución de datos en varios servidores de bases de datos.
Los componentes lógicos de acceso a datos no deben:
Invocar a otros componentes lógicos de acceso a datos. Un diseño en el que los componentes
lógicos de acceso a datos no invocan a los otros componentes del mismo tipo facilita mantener la
previsibilidad de los datos y, por tanto, aumenta la facilidad del mantenimiento de la aplicación.
Inicializar transacciones heterogéneas. Debido a que cada uno de los componentes lógicos de
acceso a datos sólo trata con un único origen de datos, no puede existir un escenario en el que
uno de estos componentes constituya la raíz de una transacción heterogénea. En determinados
casos, sin embargo, un componente lógico de acceso a datos puede controlar una transacción que
conlleve varias actualizaciones en un único origen de datos.
Mantener el estado entre llamadas a métodos.
Diseño de la interfaz de componentes lógicos de acceso a datos
35 de 41 08/10/2009 05:29 p.m.

Los componentes lógicos de acceso a datos suelen requerir una interfaz para los siguientes clientes:
Componentes y flujos de trabajo empresariales. Los componentes lógicos de acceso a datos

necesitan ofrecer E/S de documentos empresariales desconectados y escalares en métodos de
estilo funcionales sin estado, como GetOrderHeader().
Componentes de interfaz de usuario. Los componentes de interactuación de usuario pueden

utilizar componentes lógicos de acceso a datos para E/S de documentos empresariales
desconectados para el procesamiento de datos en clientes enriquecidos y escenarios de cliente
desconectados, o para la transmisión de salida (por ejemplo, obteniendo un elemento
DataReader) para ASP.NET y clientes que se benefician del procesamiento de secuencias.
Considere el uso de componentes lógicos de acceso a datos directamente de la interfaz de usuario
si desea beneficiarse de las ventajas que aporta el mayor rendimiento de este diseño y no
necesita hacer uso de lógica empresarial adicional entre la interfaz de usuario y el origen de
datos.
Los componentes de acceso a datos pueden conectarse a la base de datos utilizando directamente una API de
acceso a datos como ADO.NET, o bien, puede decidir proporcionar un componente de ayuda de acceso a datos
adicional en aplicaciones más complejas para abstraer las complejidades que entraña el acceso a la base de
datos. En cualquier caso, intente utilizar procedimientos almacenados para realizar la recuperación o
modificación real de los datos al utilizar una base de datos relacional.
Los métodos que expone un componente lógico de acceso a datos puede realizar los siguientes tipos de
tareas:
Funcionalidad habitual relacionada con la administración de "entidades", como las funciones

CRUD.
Consultas que pueden conllevar la obtención de datos de un gran número de tablas con
propósitos de sólo lectura. Los datos se pueden devolver como paginados o no paginados, en
función de los requisitos específicos, y los resultados se pueden transmitir o no dependiendo de si
el llamador se puede beneficiar de ellos.
Acciones que actualizarán y, potencialmente, devuelven datos.
Devolución de metadatos relacionados con los esquemas de entidades, parámetros de consulta y

esquemas de conjuntos de resultados.
Paginación de las interfaces de usuario que requieran subconjuntos de datos, como el

desplazamiento a través de una lista extensa de productos.
Entre los parámetros de entrada a los métodos de componentes lógicos de acceso a datos se suelen encontrar
los valores escalares y documentos empresariales representados por cadenas XML o conjuntos de datos. Los
valores de devolución pueden ser escalares, conjuntos de datos, DataReader, cadenas XML u otro tipo de
formato de datos. Si desea obtener información sobre el diseño e implementación al elegir un formato de
datos para sus objetos, consulte "Diseño de componentes de niveles y traspaso de los datos a través de éstos
[ http://www.microsoft.com/spanish/msdn/articulos/archivo/221102/voices/BOAGag.asp ] " en MSDN
Ejemplo de componente lógico de acceso a datos
El siguiente código en C# muestra un esquema parcial del esqueleto de un componente lógico de acceso a
datos simple que se podría utilizar para el acceso a los datos del pedido. Este código no se proporciona como
plantilla para el código, sino para ilustrar algunos de los conceptos descritos en este artículo.
public class OrderData

{
private string conn_string;
public OrderData()
{
// obtener la cadena de conexión de una ubicación segura o
// cifrada y asignarla a conn_string
}
public DataSet RetrieveOrders()
{
// Código para recuperar un conjunto de datos que contiene los datos de los pedidos
}
public OrderDataSet RetrieveOrder(Guid OrderId)
{
// Código para devolver un conjunto de datos introducido llamado OrderDataSet
// que representa un pedido específico.
36 de 41 08/10/2009 05:29 p.m.

// (OrderDataSet tendrá un esquema que se ha definido en Visual Studio)

}
public void UpdateOrder(DataSet updatedOrder)
{
// código para actualizar la base de datos en función de las propiedades
// de los datos del pedido enviados como parámetro de tipo conjunto de datos
}
}
Recomendaciones relativas al diseño de componentes lógicos de acceso a datos
Tenga en cuenta las siguientes recomendaciones generales relativas al diseño de componentes lógicos de
acceso a datos:
Devuelva sólo los datos que necesita. Mejorará el rendimiento y aumentará el nivel de
escalabilidad.
Utilice procedimientos almacenados para abstraer el acceso a datos del esquema de datos
subyacentes. No obstante, preste atención a no hacer un uso excesivo de este tipo de
procedimientos, ya que ello repercutirá negativamente en la facilidad de mantenimiento de la
aplicación en cuanto a código y reutilización. Un síntoma de uso excesivo de procedimientos
almacenado es disponer de grandes árboles de procedimientos almacenados que se llaman entre
sí. Evite el uso de procedimientos almacenados para implementar el control de flujo, manipular
valores individuales (por ejemplo, realizar manipulaciones de cadenas) o implementar otro tipo
de funcionalidad que resulte difícil de implementar en Transact-SQL.
Básese en la funcionalidad RDBMS para las tareas que conlleven el uso de un gran volumen de
datos. Siga el siguiente principio: "Desplace el procesamiento a los datos, no al contrario".
Encuentre un equilibrio en el uso de los procedimientos almacenados y la facilidad de
mantenimiento y reutilización de la lógica de datos.
Implemente un conjunto estándar o esperado de procedimientos almacenados proporcionando

funcionalidad habitualmente utilizada, como funciones de inserción, lectura, actualización y
localización. Ello ahorrará tiempo al desarrollar componentes empresariales. Si toma una actitud
proactiva hacia la implementación de esta funcionalidad, podrá realizar las implementaciones de
forma coherente y aplicar estándares internos. Si el diseño parece repetitivo, puede incluso
utilizar generadores de código para crear procedimientos almacenados repetitivos básicos y lógica
de componentes lógicos de acceso a datos.
Exponga la funcionalidad esperada habitual en todos los componentes lógicos de acceso a datos
en una interfaz definida de forma independiente o clase base.
Diseñe interfaces coherentes para clientes diferentes:
Los componentes empresariales se pueden implementar de diversos modos, entre los

que se incluye el uso de código .NET personalizado, reglas BizTalk Orchestration o un
motor de reglas empresariales de terceros. El diseño de la interfaz para los
componentes lógicos de acceso a datos debe ser compatible con los requisitos de
implementación de sus componentes empresariales actuales y potenciales para evitar
interfaces, fachadas o capas de asignación adicionales entre ambos.
Las interfaces de usuario basadas en ASP.NET se beneficiarán en cuanto a

rendimiento del procesamiento de datos expuestos como elementos DataReader.
Estos elementos son muy adecuados para operaciones de avance de sólo lectura en
las que el procesamiento de cada fila es bastante rápido. Si implementa los
componentes lógicos de acceso a datos junto con la interfaz de usuario, debería
exponer un gran volumen de resultados de consulta para el procesamiento en las
funciones de componentes lógicos de acceso a datos que devuelven elementos
DataReader. Si pretende utilizar datos durante un largo período de tiempo, puede
mejorar la escalabilidad del sistema basándose en un conjunto de datos en lugar de
en un elemento DataReader.
Haga que los componentes lógicos de acceso a datos exponga metadatos (por ejemplo, esquemas
y títulos de columnas) para los datos y operaciones con los que trata. De este modo, aumentará
el nivel de flexibilidad de las aplicaciones en tiempo de ejecución, sobre todo al procesar datos en
interfaces de usuario.
37 de 41 08/10/2009 05:29 p.m.

No cree necesariamente un componente lógico de acceso a datos por tabla. Se recomienda

diseñar los componentes lógicos de acceso a datos para representar un nivel de abstracción y
desnormalización ligeramente superior que los procesos empresariales puedan consumir. No es
frecuente exponer una tabla de relaciones como tal. En su lugar, se debería exponer la
funcionalidad de la relación como operaciones de datos con los componentes lógicos de acceso a
datos relacionados. Por ejemplo, en una base de datos en la que una tabla TitleAuthor facilita una
relación de varios a varios entre libros y autores, no debe crear un componente lógico de acceso a
datos para TitleAuthor, sino proporcionar un método AddBook a un componente lógico de acceso
a datos Author o un método AddAuthor a un componente lógico de acceso a datos Book. Desde el
punto de vista semántico, puede agregar un libro a un autor o un autor a un libro, pero no puede
"insertar autores".
Si almacena datos cifrados, los componentes lógicos de acceso a datos deberían realizar el
descifrado (a no ser que desee que los datos cifrados vayan directamente al cliente).
Si aloja los componentes empresariales en Enterprise Services (COM+), cree los componentes
lógicos de acceso a datos como componentes de servicios e impleméntelos en Enterprise Services
como una aplicación de biblioteca. De este modo, podrán participar y votar de forma explícita en
las transacciones Enterprise Services y utilizar autorización basada en funciones. Los
componentes lógicos de acceso a datos no necesitan alojarse en Enterprise Services si no va a
utilizar ninguno de los servicios o se van a cargar en el mismo elemento AppDomain que un
llamador de Enterprise Services. Si desea obtener más información sobre el uso de los Servicios
de Enterprise Server, consulte la sección "Componentes y flujos de trabajo empresariales"
incluida en este capítulo.
Habilite transacciones sólo cuando las necesite. No marque todos los componentes lógicos de
acceso a datos como requiere transacciones, ya que ello utilizaría recursos y resulta innecesario
para las operaciones de lectura realizadas por la interfaz de usuario. En su lugar, márquelas como
es compatible con las transacciones agregando el siguiente atributo:
[Transaction (TransactionOption.Supported)]
Considere el ajuste de los niveles de aislamiento para las consultas de datos. Si crea una
aplicación con requisitos de rendimiento alto, tal vez sea necesario realizar operaciones de datos
especiales a niveles de aislamiento inferiores que el resto de la transacción. La combinación de los
niveles de aislamiento puede repercutir de forma negativa en la coherencia de los datos, por lo
que debe analizar con cuidado esta opción en función de cada caso en concreto. Se recomienda
definir los niveles de aislamiento de transacciones sólo en la raíz de la transacción (es decir, los
componentes de los procesos empresariales). Si desea obtener más información, consulte la
sección Diseño de capas empresariales incluida en este capítulo.
Utilice componentes de ayuda de acceso a datos. Para obtener más información sobre este
enfoque, así como las ventajas que éste aporta, consulte la sección Diseño de componentes de
ayuda de acceso a datos incluida en este capítulo.
Si desea obtener más información sobre el diseño de componentes lógicos de acceso a datos, consulte ".NET
Data Access Architecture Guide" (en inglés) (http://msdn.microsoft.com/library/default.asp?url=/library
/en-us/dnbda/html/daag.asp [ http://msdn.microsoft.com/library/default.asp.aspx?url=/library/en-us/dnbda
/html/daag.asp ] ). Microsoft también proporciona Data Access Application Block (en inglés)
(http://msdn2.microsoft.com/library/ms954827.aspx), un componente de ayuda de datos de alto
rendimiento probado que puede utilizar en la aplicación.
Diseño de componentes de ayuda de acceso a datos
Cuando una aplicación requiere una gran cantidad de componentes lógicos de acceso a datos para tener
acceso al mismo origen de datos, tal vez sea preciso implementar código de datos genéricos similar en cada
uno de los componentes lógicos de acceso a datos. Esta duplicación de la lógica puede conllevar problemas de
mantenimiento, así como dificultad la solución de problemas relativos al acceso a datos. La centralización de
la funcionalidad de acceso a datos genéricos en un componente de ayuda de acceso a datos da lugar a un
diseño más limpio que resulta más fácil de administrar. Los componentes de ayuda de acceso a datos
proporcionan un modelo de invocación sencillo para el origen de datos subyacente. Puede considerar los
componentes de ayuda de acceso a datos como fachadas genéricas del lado del cliente en el origen de datos.
Estos componentes suelen ser independientes a la lógica empresarial de la aplicación que se está ejecutando.
Normalmente, sólo dispondrá de uno o dos componentes de ayuda en un origen de datos determinado. Cada
uno de ellos puede implementar conjuntos diferentes de funcionalidad técnica para el acceso al servicio. Por
ejemplo, un componente de ayuda de acceso a datos de una base de datos puede permitir invocar
procedimientos almacenados, mientras que otro puede permitir la transmisión de grandes cantidades de
datos.
38 de 41 08/10/2009 05:29 p.m.

Para diseñar una aplicación independiente del tipo de origen de datos (por ejemplo, para que pueda cambiar
entre una base de datos Oracle y una base de datos SQL Server), puede disponer de dos componentes
sencillos de acceso a datos que expongan una interfaz similar. Tenga en cuenta sin embargo que el cambio
del origen de datos debe garantizar las pruebas adicionales de la aplicación y que la transparencia de origen
de datos no es un objetivo dudoso para la mayoría de las aplicaciones, probablemente con la excepción de las
aplicaciones "ajustadas" desarrolladas por ISV.
El objetivo de utilizar un componente de ayuda de acceso a datos es:
Abstraer el modelo de programación API de acceso a datos de la lógica empresarial relacionada

con los datos encapsulados en los componentes lógicos de acceso a datos y, por tanto, reducir y
simplificar el código de dichos componentes.
Aislar la semántica de administración de conexión.
Aislar la ubicación del origen de datos (a través de la administración de las cadenas de conexión).
Aislar la autenticación del origen de datos.
Aislar la inclusión en lista de las transacciones (ADO.NET lo hace automáticamente cuando se

utiliza para obtener acceso a los datos de una base de datos SQL Server o al utilizar ODBC o
OLEDB).
Centralizar la lógica de acceso a datos para facilitar el mantenimiento, al tiempo que se minimiza
la necesidad de hacer uso de capacidades de codificación específicas del origen de datos a través
del equipo de desarrollo y se facilita la solución de problemas de acceso a datos.
Aislar las dependencias de versión de API de acceso a datos de los componentes lógicos de
acceso a datos.
Proporcionar un único punto de interceptación para el seguimiento y comprobación del acceso a

datos.
Utilizar al acceso a código y la autorización basada en usuario o función para restringir el acceso a
todo el origen de datos.
Traducir las excepciones que no pertenecen a .NET devueltas por el origen de datos en
excepciones que la aplicación pueda controlar con métodos tradicionales.
Para ver un ejemplo de un componente de ayuda de acceso a datos, incluido el código de origen y la
documentación, descargue Data Access Application Block para .NET (en inglés) de MSDN
(http://msdn2.microsoft.com/library/ms954827.aspx).
Acceso a varios orígenes de datos
Si obtiene acceso a una base de datos Oracle u otros orígenes de datos, tal vez prefiera abstraer al máximo la
API con la que obtiene acceso a dichos orígenes de los componentes lógicos de acceso a datos. Microsoft
proporciona implementaciones de Oracle y OLE DB de Data Access Application Block y las probado en el
contexto de la cota de rendimiento Nile. Puede descargar estas implementaciones en MSDN, siguiendo los
vínculos que se incluyen en este artículo: http://msdn.microsoft.com/library/default.asp?url=/library/en-us
/dndotnet/html/manprooracperf.asp [ http://msdn.microsoft.com/library/default.asp.aspx?url=/library/en-us
/dndotnet/html/manprooracperf.asp ] (en inglés).
Conseguir la transparencia de RDBMS es un objetivo de diseño bastante complejo, por lo que el uso de
componentes de ayuda de acceso a datos puede mitigar un tanto los esfuerzos de desarrollo, solución de
problemas y mantenimiento. No obstante, deberá comprobar la aplicación con cada uno de los orígenes de
datos debido a las diferentes formas en las que los sistemas de administración de bases de datos relacionales
controlar los procedimientos almacenados, cursores y otros artefactos de bases de datos.
Si lo que pretende es que la aplicación se distribuya en entornos diferentes con sistemas de administración
de bases de datos relacionales, puede implementar los componentes de ayuda de acceso a datos con una
interfaz común y proporcionar el componente que obtiene realmente el acceso a los datos a un origen de
datos determinado en un patrón predeterminado. Puede cambiar el código fuente suministrado para los
bloques de aplicación para .NET mencionados anteriormente para satisfacer estos requisitos específicos.
Integración con servicios
Si en su proceso empresarial intervienen servicios externos, será necesario controlar la semántica de la

comunicación con cada servicio al que sea necesario llamar. En concreto, deberá utilizar la API de
comunicación adecuada para llamar al servicio y realizar las traducciones necesarias entre los formatos de
datos utilizados por el servicio y los utilizados por el proceso empresarial. Si el contrato de servicio consta de
39 de 41 08/10/2009 05:29 p.m.

una conversación de ejecución larga, también deberá mantener el estado intermedio mientras espera una
respuesta.
Se recomienda utilizar un componente de agente de servicios que encapsule la lógica necesaria para
encapsular estas tareas e inicializar y administrar una conversación basada en mensajes para cada uno de los
servicios que debe consumir la aplicación. Los agentes de servicios se pueden considerar como los
componentes lógicos de acceso a datos para los servicios distintos a los almacenes de datos, o como
servidores proxy o emisarios para otros servicios. Determinados publicadores de servicios pueden
proporcionar a los llamadores un agente de servicios incorporado. En otros casos, por el contrario, puede que
sea necesario que desarrolle el suyo propio.
El objetivo de utilizar un agente de servicios es:
Encapsular el acceso a un servicio.
Aislar la implementación de los procesos empresariales de la implementación de formato de datos

o cambios de esquema
Proporcionar los formatos de datos de entrada y salida compatibles con los componentes
empresariales que llaman al servicio.
Los agentes de servicios también puedan realizar los siguientes tipos de tareas habituales si es necesario:
Llevar a cabo la validación básica de los datos intercambiados con el servicio.
Almacenar en caché los datos necesarios para realizar consultas habituales.
Autorizar el acceso al servicio, proporcionando una forma granular de comprobar la seguridad

antes de obtener acceso al servicio desde el punto de vista de la aplicación que realiza la llamada.
Normalmente, el servicio también suele autenticar y autorizar las solicitudes.
Definir la seguridad adecuada u ofrecer las credenciales necesarias al servicio para la

autenticación. Por ejemplo, para definir las credenciales para un servicio Web XML que se está
invocando, puede utilizar HTTPCredentialCache.
Asegurarse de que las partes adecuadas del mensaje están cifradas o de que se puede establecer
un canal de seguridad si es necesario.
Proporcionar información de supervisión que posibilite la interactuación con el servicio que se va a

implementar, lo que permite determinar si sus socios cumplen con sus contratos de nivel de
servicio (SLA).
Administración de conversaciones asincrónicas con servicios
En determinados casos, es necesario integrar la aplicación con otros servicios, enviando y recibiendo llamadas
asincrónicas. En este caso, las interfaces de servicios recibirán llamadas de los servicios externos y se
realizarán llamadas a dichos servicios desde los agentes de servicios. Si estos intercambios de mensajes se
implementan de modo asincrónico, tal vez sea preciso realizar el seguimiento de la conversación a la que
pertenece un determinado conjunto de intercambios de mensajes. Se recomienda que utilice una de las dos
siguientes opciones para realizar el seguimiento del estado de la conversación:
Utilice los datos empresariales de los mensajes para identificar la conversación. Por ejemplo,
puede hacer uso del número de Id. de un producto determinado en todos los mensajes para
identificar el pedido que se está procesando en un intercambio de mensajes concreto. Este el
modo más sencillo de correlacionar mensajes.
Proporcione un componente o utilidad de infraestructura que genere GUID o Id. para

conversaciones específicas y los adjunte a los mensajes. Los agentes e interfaces de servicios
deberán tener acceso a esta información con el fin de determinar el modo de interpretar una
llamada asincrónica determinada. Asimismo, es necesario disponer de una base de datos
persistente para realizar el seguimiento del estado y el Id. de cada conversación. Todo esto
requiere trabajo de desarrollo adicional. Tenga en cuenta que el contexto del mensaje se pederá
si éste se debe interpretar fuera del servicio. No obstante, resulta adecuado utilizar Id. de
correlación propios se desea mantener la confidencialidad de la información.
Si desea obtener más información sobre este tema, consulte el capítulo 3, "Directivas de seguridad,
administración operativa y comunicaciones [ http://msdn.microsoft.com/es-es/library/ms978357.aspx ] ".
40 de 41 08/10/2009 05:29 p.m.

Próximamente
En este artículo se han descrito varias recomendaciones relativas al diseño de diferentes tipos de
componentes habituales en las aplicaciones y los servicios distribuidos. En el capítulo 3, "Directivas Directivas
de seguridad, administración operativa y comunicaciones [ http://msdn.microsoft.com/es-es/library
/ms978357.aspx ] ", se describe el modo en que las políticas de organización repercuten en el diseño de la
aplicación o el servicio.
Comentarios y soporte
Si desea formular alguna pregunta, o realizar algún comentario o sugerencia sobre esta guía, envíe un
mensaje de correo electrónico a la siguiente dirección: devfdbck@microsoft.com.
41 de 41 08/10/2009 05:29 p.m.

Diseño de Aplicaciones - Diseño de Los Componentes de Una Aplicación o Servicio Cap II

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diseño de Aplicaciones - Diseño de Los Componentes de Una Aplicación o Servicio Cap II

Hochgeladen von

Copyright:

Verfügbare Formate

Directivas de seguridad, administración operativa y comunicaciones http://msdn.microsoft.com/es-es/library/ms978348(printer).

©2009 Microsoft Corporation. All rights reserved.

Directivas de seguridad, administración operativa y comunicaciones

Patterns & Practices

1 de 41 08/10/2009 05:29 p.m.

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:

2. Componentes de proceso de usuario. En un gran número de casos, la interactuación del usuario

4. Componentes empresariales. Independientemente de si el proceso empresarial consta de un único

2 de 41 08/10/2009 05:29 p.m.

5. Agentes de servicios. Cuando un componente empresarial requiere el uso de la funcionalidad

7. Componentes lógicos de acceso a datos. La mayoría de las aplicaciones y servicios necesitan

8. Componentes de entidad empresarial. La mayoría de la aplicaciones requieren el paso de datos

9. Componentes de seguridad, administración operativa y comunicación. La aplicación

Recomendaciones generales relativas al diseño de aplicaciones y servicios

Tenga en cuenta las siguientes recomendaciones al diseñar una aplicación o servicio:

Mantenga la coherencia en la aplicación o el servicio en cuanto al formato utilizado para el

3 de 41 08/10/2009 05:29 p.m.

Diseño de capas de presentación

Figura 2.2. Capa de presentación

4 de 41 08/10/2009 05:29 p.m.

Diseño de componentes de interfaz de usuario

Figura 2.3. Diseño de interfaz de usuario

Funcionalidad de los componentes de interfaz de usuario

Los componentes de interfaz de usuario:

No inicializan, participan ni votan en transacciones.

Pueden encapsular tanto la funcionalidad de visualización como un controlador.

Al aceptar la entrada del usuario, los componentes de la interfaz:

Llevan a cabo la asignación y transformación simple de la información proporcionada por los

5 de 41 08/10/2009 05:29 p.m.

Pueden utilizar un componente de utilidad para el almacenamiento de datos en caché. En

Pueden utilizar un componente de utilidad para realizar la paginación. Es frecuente,

Al procesar datos, los componentes de interfaz de usuario:

Realizan el formato de valores (como el formato adecuado de las fechas).

Pueden utilizar un componente de utilidad para proporcionar funcionalidad de deshacer. Un gran

Pueden utilizar un componente de utilidad para proporcionar funcionalidad de portapapeles. En

Interfaces de usuario del Escritorio de Windows

Las interfaces de usuario de Windows se utilizan cuando es necesario proporcionar capacidades de

6 de 41 08/10/2009 05:29 p.m.

Interfaces de usuario completas de PC de escritorio o Tablet PC incorporadas en

Intente evitar las relaciones de modificación entre formularios y básese en el componente de

7 de 41 08/10/2009 05:29 p.m.

ventana de excepciones .NET no descriptiva y que la aplicación dé error si las excepciones no se

Implemente las funciones de control como funciones independientes en los formularios de

Por ejemplo, el controlador de eventos de un botón de comando, denominado evento de clic de

private void addItem_Click(object sender, System.EventArgs e)

public void AddItemToBasket(int ProductID, int Quantity)

Interfaces de usuario de exploración de Internet

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.

Implemente una página de error personalizada y un controlador de excepciones global en

8 de 41 08/10/2009 05:29 p.m.

<asp:Button id="addItem" OnClick="addItem_Click"/>

private void addItem_Click(object sender, System.EventArgs e)

public void AddItemToBasket(int ProductID, int Quantity)

En un gran número de aplicaciones, resulta importante proporcionar un marco extensible en el que se

Microsoft Content Management Server [ http://msdn.microsoft.com/library/default.asp.aspx?url=

9 de 41 08/10/2009 05:29 p.m.

Microsoft SharePoint Portal™ Server 2001 [ http://msdn.microsoft.com/library

IBuySpy Portal [ http://msdn.microsoft.com/library/en-us/dnbda/html/bdasampibsport.asp ] (en