Directivas de seguridad, administración operativa y comunicaciones

Publicado: 26 de junio de 2006

Patterns & Practices
Microsoft Corporation
Diciembre de 2002

imagen

http://msdn.microsoft.com/practices/

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í para obtener una visión general completa.

En esta página

Tipos de componentes  Tipos de componentes
Recomendaciones generales relativas al diseño de aplicaciones y servicios Recomendaciones generales relativas al diseño de aplicaciones y servicios
Diseño de capas de presentación Diseño de capas de presentación
Diseño de capas empresariales Diseño de capas empresariales
Diseño de capas de datos Diseño de capas de datos
Próximamente 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.

imagen

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 costo adicional correspondiente por el envío del mismo. Los componentes empresariales implementan la lógica empresarial de la aplicación.

  5. Agentes de servicios. Cuando un componente empresarial requiere el uso de la funcionalidad proporcionada por un servicio externo, tal vez sea necesario hacer uso de código para administrar la semántica de la comunicación con dicho servicio. Por ejemplo, los componentes empresariales de la aplicación comercial descrita anteriormente podría utilizar un agente de servicios para administrar la comunicación con el servicio de autorización de tarjetas de crédito y utilizar un segundo agente de servicios para controlar las conversaciones con el servicio de mensajería. Los agentes de servicios permiten aislar las idiosincrasias de las llamadas a varios servicios desde la aplicación y pueden proporcionar servicios adicionales, como la asignación básica del formato de los datos que expone el servicio al formato que requiere la aplicación.

  6. Interfaces de servicios. Para exponer lógica empresarial como un servicio, es necesario crear interfaces de servicios que admitan los contratos de comunicación (comunicación basada en mensajes, formatos, protocolos, seguridad y excepciones, entre otros) que requieren los clientes. Por ejemplo, el servicio de autorización de tarjetas de crédito debe exponer una interfaz de servicios que describa la funcionalidad que ofrece el servicio, así como la semántica de comunicación requerida para llamar al mismo. Las interfaces de servicios también se denominan fachadas empresariales.

  7. Componentes lógicos de acceso a datos. La mayoría de las aplicaciones y servicios necesitan obtener acceso a un almacén de datos en un momento determinado del proceso empresarial. Por ejemplo, la aplicación empresarial necesita recuperar los datos de los productos de una base de datos para mostrar al usuario los detalles de los mismos, así como insertar dicha información en la base de datos cuando un usuario realiza un pedido. Por tanto, es razonable abstraer la lógica necesaria para obtener acceso a los datos en un capa independiente de componentes lógicos de acceso a datos, ya que de este modo se centraliza la funcionalidad de acceso a datos y se facilita la configuración y el mantenimiento de la misma.

  8. Componentes de entidad empresarial. La mayoría de la aplicaciones requieren el paso de datos entre distintos componentes. Por ejemplo, en la aplicación comercial es necesario pasar una lista de productos de los componentes lógicos de acceso a datos a los componentes de la interfaz de usuario para que éste pueda visualizar dicha lista. Los datos se utilizan para representar entidades empresariales del mundo real, como productos o pedidos. Las entidades empresariales que se utilizan de forma interna en la aplicación suelen ser estructuras de datos, como conjuntos de datos, DataReader o secuencias de lenguaje de marcado extensible (XML), aunque también se pueden implementar utilizando clases orientadas a objetos personalizadas que representan entidades del mundo real necesarias para la aplicación, como productos o pedidos.

  9. Componentes de seguridad, administración operativa y comunicación. La aplicación probablemente utilice también componentes para realizar la administración de excepciones, autorizar a los usuarios a que realicen tareas determinadas y comunicarse con otros servicios y aplicaciones. Estos componentes se describen en detalle en el capítulo 3: "Directivas de seguridad, administración operativa y comunicaciones".

Recomendaciones generales relativas al diseño de aplicaciones y servicios

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

  • Identifique los distintos tipos de componentes que necesitará utilizar en la aplicación. Ciertas aplicaciones no requieren el uso de determinados componentes. Por ejemplo, puede que las aplicaciones de menor tamaño que no necesitan integrarse con otros servicios no requieran flujos de trabajo empresariales ni agentes de servicios. 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 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.

imagen

Figura 2.2. Capa de presentación

En el caso de la aplicación comercial, son necesarias dos interfaces de usuario: una para el sitio Web de comercio electrónico que utiliza el cliente y otra para las aplicaciones basadas en formularios de Windows Forms utilizados por los representantes de ventas. Ambos tipos de usuario realizan tareas similares a través de estas interfaces. Por ejemplo, ambas interfaces deben permitir ver todos los productos disponibles, agregar productos a una cesta de compra y especificar los detalles de pago como parte de un proceso de desprotección. Este proceso se puede realizar a parte en un componente de proceso de usuario independiente para facilitar el mantenimiento de la aplicación.

Diseño de componentes de interfaz de usuario

La implementación de interfaces de usuario se puede llevar a cabo de varias formas. Por ejemplo, la aplicación comercial requiere una interfaz basada en el Web y otra basada en Windows. Otros tipos de interfaces de usuario incluyen procesamiento de voz, programas basados en documentos y aplicaciones de cliente móviles, entre otros. Los componentes de la interfaz de usuario administran la 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.

imagen

Figura 2.3. Diseño de interfaz de usuario

Funcionalidad de los componentes de interfaz de usuario

Los componentes de la interfaz de usuario deben mostrar datos al usuario, obtener y validar los datos procedentes del mismo e interpretar las acciones de éste que indican que desea realizar una operación con los datos. Asimismo, la interfaz debe filtrar las acciones disponibles con el fin de permitir al usuario realizar sólo aquellas operaciones que le sean necesarias en un momento determinado.

Los componentes de interfaz de usuario:

  • No inicializan, participan ni votan en transacciones.

  • Presentan una referencia al componente de proceso de usuario actual si necesitan mostrar sus datos o actuar en su estado.

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

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

  • Adquieren los datos del usuario y atienden su entrada utilizando guías visuales (como informaciones sobre herramientas) y sistemas de validación, así como los controles necesarios para realizar la tarea en cuestión.

  • Capturan los eventos del usuario y llaman a las funciones de control para indicar a los elementos de la interfaz de usuario que cambien el modo de visualización de los datos, bien inicializando una acción en el proceso de usuario actual, o bien, modificando los datos del mismo.

  • Restringen los tipos de entrada del usuario. Por ejemplo, un campo Quantity puede limitar las entradas del usuario a valores numéricos.

  • Realizan la validación de entrada de datos, por ejemplo, restringiendo el intervalo de valores que se pueden escribir en un campo determinado, o garantizando que se escriben los datos obligatorios.

  • Llevan a cabo la asignación y transformación simple de la información proporcionada por los controles del usuario en los valores necesarios para que los componentes subyacentes realicen su trabajo (por ejemplo, un componente de interfaz de usuario puede mostrar el nombre de un producto pero pasar el Id. del mismo a los componentes subyacentes).

  • Interpretar las acciones del usuario (como las operaciones de arrastrar y colocar o los clics de botones) y llamar a una función de control.

  • Pueden utilizar un componente de utilidad para el almacenamiento de datos en caché. En ASP.NET, puede especificar el almacenamiento en caché de la salida de un componente determinado de la interfaz de usuario para evitar el continuo procesamiento del mismo. Si la aplicación contiene elementos visuales que representan datos de referencia que no cambian con frecuencia y no se utilizan en contextos transaccionales, y un gran número de usuarios comparte dichos elementos, se recomienda que los almacene en caché. Se aconseja almacenar en caché aquellos elementos visuales compartidos por un gran número de usuarios, que representan datos de referencia que no cambian con frecuencia y no se utilizan en contextos transaccionales.

  • Pueden utilizar un componente de utilidad para realizar la paginación. Es frecuente, especialmente en las aplicaciones Web, mostrar largas listas de datos como conjuntos paginados. Asimismo, se suele disponer de un componente de ayuda para realizar el seguimiento de la página actual en la que se encuentra el usuario y, por tanto, invocar a las funciones de consulta paginada de los componentes lógicos de acceso a datos con los valores adecuados relativos al tamaño de página y página actual. La paginación se puede realizar sin la 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 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).

Tenga en cuenta las siguientes recomendaciones al crear aplicaciones basadas en Windows Forms:

  • Básese en el enlace a datos para mantener la sincronización de los mismos en varios formularios abiertos de forma simultánea. De este modo, disminuirá la necesidad de escribir código complejo de sincronización de datos.

  • Intente evitar las relaciones de modificación entre formularios y básese en el componente de proceso de usuario para abrirlos y sincronizar los datos y eventos. Sea especialmente cuidadoso en evitar este tipo de relaciones entre los formularios secundarios y primarios. Por ejemplo, la ventana de detalles de un producto determinado se puede volver a utilizar en otras ubicaciones de la aplicación, no sólo en un formulario de entrada de pedido, por lo que debe evitar la implementación de funcionalidad en el formulario de detalles del producto que enlaza directamente al formulario de entrada del pedido. Esto aumenta el nivel de reutilización de los elementos de la interfaz de usuario.

  • Implemente controladores de errores en sus formularios para evitar que el usuario vea una ventana de excepciones .NET no descriptiva y que la aplicación dé error si las excepciones no se controlan en ninguna otra ubicación. Todos los controladores de eventos y las funciones de control deben incluir capturas de excepciones. Asimismo, tal vez desee crear una clase de excepción personalizada para la interfaz de usuario que incluya metadatos para determinar si la operación errónea se puede recuperar o cancelar.

  • Valide la entrada del usuario en la interfaz de usuario. La validación debe tener lugar en las fases de la tarea o del proceso del usuario en las que se permiten las validaciones a un momento dado (lo que posibilita al usuario escribir los datos necesarios, continuar con otra tarea y volver a la tarea actual). En determinados casos, se recomienda habilitar o deshabilitar de forma proactiva los controles y guiar de modo visual al usuario en caso de que se escriban datos no válidos. La validación de la entrada del usuario en la interfaz evita recorridos de ida y vuelta innecesarios a los componentes del lado del servidor al escribir datos no válidos.

  • Si crea controles de usuario personalizados, exponga sólo las propiedades y los métodos públicos que realmente necesita con el fin de facilitar el mantenimiento de los componentes.

  • Implemente las funciones de control como funciones independientes en los formularios de Windows Forms o en las clases .NET que se van a implementar con el cliente. No implemente la funcionalidad de control directamente en los controladores de eventos de control. Si escribe la lógica de control en controladores de eventos, reducirá la facilidad de mantenimiento de la aplicación, ya que en el futuro tal vez sea necesario invocar a la misma función desde otros eventos.

    Por ejemplo, el controlador de eventos de un botón de comando, denominado evento de clic de addItem, debe llamar a un procedimiento más general para realizar su tarea, tal y como se muestra en el siguiente código.

    private void addItem_Click(object sender, System.EventArgs e)
    {
      AddItemToBasket(selectedProduct, selectedQuantity)
    }
    
    public void AddItemToBasket(int ProductID, int Quantity)
    {
      // código para agregar el artículo a la cesta
    }
    

Interfaces de usuario de exploración de Internet

La aplicación comercial descrita en esta guía requiere una interfaz de usuario basada en el Web que permita a los clientes realizar pedidos a través de Internet. Las interfaces de usuario basadas en el Web permiten el uso de interfaces de usuario basadas en estándares en un gran número de dispositivos y plataformas. Para desarrollar interfaces de usuario basadas en el Web para aplicaciones basadas en .NET se utiliza ASP.NET. Éste ofrece un entorno enriquecido en el que se pueden crear interfaces complejas basadas en el Web con compatibilidad para características importantes, como por ejemplo:

  • Un entorno de desarrollo coherente que también se utiliza para crear otros componentes de la aplicación.

  • Enlace a datos de interfaz de usuario.

  • Interfaces de usuario basadas en componentes con controles.

  • Acceso al modelo de seguridad .NET integrado.

  • Almacenamiento en caché enriquecido y opciones de administración de estado.

  • Disponibilidad, rendimiento y escalabilidad del procesamiento Web.

Cuando necesite implementar una aplicación para un explorador, ASP.NET ofrece la funcionalidad necesaria para publicar una interfaz de usuario basada en páginas Web. Considere las siguientes recomendaciones relativas al diseño de interfaces de usuario de ASP.NET:

  • Implemente una página de error personalizada y un controlador de excepciones global en Global.asax. De este modo, dispondrá de una función completa de detección de excepciones que evitará que el usuario vea páginas no descriptivas en caso de que ocurra algún problema.

  • ASP.NET presenta un marco de validación enriquecido que optimiza la tarea de garantizar que los datos escritos por el usuario se ajusten a determinados criterios. No obstante, la validación de clientes que se realiza en el explorador se basa en que JavaScript está habilitado en el cliente, por lo que también debe validar los datos en las funciones de control, en caso de que un usuario disponga de un explorador no compatible con JavaScript (o tenga JavaScript deshabilitado). Si su proceso de usuario dispone de una función de control de validación, llámelo antes de pasar a otras páginas para llevar a cabo la validación a un momento dado.

  • Si crea controles de usuario Web, exponga sólo las propiedades y los métodos públicos que realmente necesita. De este modo, aumentará la facilidad del mantenimiento.

  • Utilice el estado de vista de ASP.NET para almacenar el estado específico de las páginas y mantener el estado de sesión y aplicación de los datos con un alcance más amplio. Este enfoque facilita el mantenimiento y aumenta el nivel de escalabilidad.

  • Las funciones de control deben invocar a las acciones del componente de proceso de usuario para guiar al usuario a través de la tarea actual, en lugar de redireccionarlo a la página directamente. El componente del proceso de usuario puede llamar a la función Redirect para que el servidor muestre una página diferente. Para ello, debe hacer referencia al espacio de nombres System.Web desde los componentes de proceso de usuario. (Tenga en cuenta que, por tanto, el componente de proceso de usuario no se podrá volver a utilizar en aplicaciones basadas en el Web, por lo que resulta adecuado implementar llamadas de redirección en una clase diferente).

  • Implemente las funciones de control como funciones independientes en las páginas ASP.NET o en las clases .NET que se distribuirán con las páginas Web. Si escribe la lógica empresarial en los controladores de eventos proporcionados por ASP.NET, reducirá la facilidad de mantenimiento del sitio, ya que tal vez sea necesario en el futuro invocar a la misma función desde otros eventos. Para ello, se requiere una mayor capacidad por parte de los desarrolladores que escriben código exclusivo de IU.

    Suponga, por ejemplo, que el sitio Web comercial contiene una página en la que se puede hacer clic en un botón de comando para agregar un producto a la cesta de compra del usuario. El marcado ASP.NET del control podría tener el aspecto de la siguiente línea de código.

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

    Como puede observar en el código, la función addItem_Click controla el evento OnClick del botón. No obstante, el controlador de eventos no debe contener el código que realiza la acción requerida (en este caso, agregar un elemento de la cesta), sino que debe llamar a otra función general, como se muestra en el siguiente fragmento de código.

    private void addItem_Click(object sender, System.EventArgs e)
    {
      AddItemToBasket(selectedProduct, selectedQuantity)
    }
    
    public void AddItemToBasket(int ProductID, int Quantity)
    {
      // código para agregar el artículo a la cesta
    }
    

    Esta capa de abstracción adicional garantiza que otros elementos de la interfaz de usuario puedan utilizar el código requerido para realizar las tareas de control.

Si desea obtener información general sobre ASP.NET, consulte la sección de ASP.NET (en inglés) de MSDN (http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000440) y el sitio oficial de ASP.NET (en inglés) (http://asp.net).

En un gran número de aplicaciones, resulta importante proporcionar un marco extensible en el que se muestren varios paneles con diferentes objetivos. En las aplicaciones basadas en el Web, también es preciso proporcionar una página principal o interfaz de usuario raíz en la que se muestren las tareas y la información relevante al usuario en función del contexto y dispositivo utilizado. Microsoft proporciona los siguientes recursos para facilitar la implementación de portales basados en el Web:

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 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 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:

Puede administrar flujos de trabajo basados en documentos beneficiándose de las ventajas que aportan los servicios que proporciona Microsoft SharePoint Portal™. Este producto puede administrar el proceso de usuario y proporcionar metadatos enriquecidos y capacidades de búsqueda.

Acceso a componentes lógicos de acceso a datos desde la interfaz de usuario

Las interfaces de usuario de determinadas aplicaciones necesitan procesar los datos disponibles como consultas expuestas por los componentes lógicos de acceso a datos. Independientemente de si los componentes de la interfaz de usuario invocan directamente a los componentes lógicos de acceso a datos, se recomienda no mezclar la lógica de acceso a datos con la lógica de procesamiento empresarial.

El acceso directo a los componentes lógicos de acceso a datos desde la interfaz de usuario parece contradecir el concepto de disposición en capas. No obstante, resulta útil en este caso considerar a la aplicación como un servicio homogéneo; se llama a la aplicación y ésta decide cuáles son los componentes internos más adecuados para responder a una solicitud determinada.

Se recomienda permitir a los componentes lógicos de acceso a datos el acceso directo a los componentes de la interfaz de usuario cuando:

  • Está dispuesto a relacionar estrechamente los métodos y esquemas de acceso a datos con la semántica de la interfaz de usuario. Esta relación requiere el mantenimiento conjunto de los cambios de la interfaz de usuario y de los esquemas.

  • La implementación física coloca juntos a los componentes lógicos de acceso a datos y a los componentes de interfaz de usuario, lo que permite obtener datos en formatos de secuencias (como DataReader) de los componentes lógicos de acceso a datos, que se pueden enlazar directamente a la salida de las interfaces de usuario ASP.NET para obtener un mayor rendimiento. Si implementa la lógica de acceso a datos y de los procesos empresariales en servidores diferentes, no podrá beneficiarse de esta capacidad. Desde el punto de vista del funcionamiento, permitir el acceso directo a los componentes lógicos de acceso a datos para poder hacer uso de las capacidades de transmisión conlleva la necesidad de proporcionar acceso a la base de datos en la que se distribuyen los componentes lógicos de acceso a datos; incluido probablemente el acceso a través de puertos de servidores de seguridad. Si desea obtener más información, consulte el capítulo 4: "Implementación física y requisitos operativos".

Diseño de componentes de proceso de usuario

La 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();
      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.

imagen

Figura 2.4. Interfaces de usuario y componentes de proceso de usuario

Los componentes de proceso de usuario ayudan a resolver los siguientes problemas de diseño de interfaces de usuario:

  • Control de actividades de usuarios concurrentes. Determinadas aplicaciones permiten a los usuarios realizar varias tareas a la vez poniendo a su disposición más de un elemento de interfaz. Por ejemplo, una aplicación basada en Windows puede mostrar varios formularios, o una aplicación Web puede abrir una segunda ventana de exploración.
    Los componentes de proceso de usuario simplifican la administración del estado de varios procesos salientes encapsulando todo el estado necesario para el proceso en un solo componente. Puede asignar cada elemento de interfaz a una instancia determinada del proceso de usuario incorporando un identificador de procesos personalizado en el diseño.

  • Uso de varios paneles para una actividad. Si utiliza varias ventanas o paneles en una actividad de usuario determinada, es importante mantenerlos sincronizados. En una aplicación Web, una interfaz de usuario normalmente muestra un conjunto de elementos en una misma página (que puede incluir marcos) para una actividad de usuario dada. No obstante, en las aplicaciones de cliente enriquecidas, puede disponer de varias ventanas no modales que afectan a un solo proceso. Por ejemplo, puede disponer de una ventana flotante de selección de categorías de productos en la aplicación que permita especificar una categoría determinada, los productos de la cual se mostrarán en otra ventana.
    Asimismo, los componentes de proceso de usuario facilitan la implementación de este tipo de interfaz a través de la centralización del estado de todas las ventanas en una única ubicación. Puede simplificar aún más la sincronización en varios elementos de la interfaz utilizando formatos de enlace a datos para los datos de estado.

  • Aislamiento de las actividades de usuario de ejecución larga del estado empresarial. Determinados procesos de usuario se pueden poner en pausa y posteriormente reanudar. El estado intermedio del proceso de usuario se debe almacenar por lo general en una ubicación distinta a la de los datos empresariales de la aplicación. Por ejemplo, un usuario puede especificar cierta información necesaria para realizar un pedido y, a continuación, reanudar el proceso de desprotección. Los datos de pedido pendiente se deben mantener en una ubicación distinta a la de los datos de los pedidos completados, lo que permite realizar operaciones empresariales con los datos de los pedidos completados (por ejemplo, contar el número de pedidos realizados en el mes actual) sin tener que implementar reglas complejas de filtrado para evitar el uso de pedidos no completados.
    Las actividades de usuario, al igual que los procesos empresariales, pueden presentar un "tiempo de espera" específico cuando es necesario cancelar la actividad y se deben llevar a cabo las acciones de compensación adecuadas en el proceso empresarial.
    Puede diseñar los componentes de proceso de usuario para que se puedan serializar, o almacenar su estado en una ubicación distinta a la de los datos empresariales de la aplicación.

Separación de un proceso de usuario de la interfaz de usuario

Para separar un proceso de usuario de la interfaz de usuario:

  1. Identifique el proceso o los procesos empresariales que el proceso de interfaz de usuario ayudará a realizar. Identifique el modo en que el usuario ve este proceso como una tarea (normalmente lo puede hacer consultando los diagramas de secuencia creados como parte del análisis de requisitos).

  2. Identifique los datos que necesitan los procesos empresariales. El proceso de usuario necesitará ser capaz de enviar datos cuando sea necesario.

  3. Identifique el estado adicional que necesitará mantener a lo largo de la actividad del usuario para ayudar al procesamiento y la captura de datos en la interfaz de usuario.

  4. Diseñe el flujo visual del proceso de usuario y el modo en que cada elemento de la interfaz recibe o da flujo de control.

Asimismo, necesitará implementar código para asignar una sesión de interfaz de usuario determinada al proceso de usuario relacionado:

  • Las páginas ASP.NET tendrán que obtener el proceso de usuario actual a través de una referencia del objeto Session o utilizando el proceso desde otro medio de almacenamiento, como una base de datos. Necesitará esta referencia en los controladores de eventos para los controles de la página Web.

  • Las ventanas y controles necesitan mantener una referencia al componente de proceso de usuario actual. Puede mantener esta referencia en una variable de miembro. Sin embargo, se recomienda que no mantenga la referencia en una variable global, ya que, si lo hace, la composición de interfaces de usuario pasará a ser una tarea bastante compleja a medida que aumenta el tamaño de la interfaz.

Funcionalidad de los componentes de proceso de usuario

Los componentes de proceso de usuario:

  • Proporcionan un modo simple de combinar los elementos de la interfaz de usuario en los flujos de 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.

  • 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.

imagen

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

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".

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 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)

  • 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 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.

imagen

Figura 2.6. Capas de componentes empresariales

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 (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).

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).

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). 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.

    • 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.

imagen

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

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 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).

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.

    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).

  • 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).

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 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).

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).

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.

imagen

Figura 2.8. Un proceso empresarial organizado

Observe los siguientes puntos en la figura 2.8:

  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.

  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.

imagen

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).

Si desea obtener más información sobre los adaptadores de BizTalk:

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/

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 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 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.

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.

imagen

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.

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" 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.

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.

  • 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" 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.

imagen

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).

  • 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 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.

imagen

Figura 2.12. Componentes lógicos de acceso a datos

Observe los siguientes puntos en la figura 2.12:

  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.

  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

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" 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.
    // (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.

  • 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). 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.

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 (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 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".

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", 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.

Mostrar: