Microsoft Corporation

April 2004

Summary: Chapter 1 introduces the UIP block and reviews concepts that are important to the understanding of the block.

Contents

Who Should Read This Guide
User Interface Process Concepts
Goals of the UIP Application Block
Features of the User Interface Process Application Block
Chapter Overview
Conclusion

Applications typically contain code to manage user interaction in the presentation layer; for example, one form can determine the next form that a user navigates to. Developers often write all of this code within the user interface (UI) code itself. However, if a developer includes navigation code in the user interface, the resulting code can be complex and very difficult to reuse, maintain, or extend. In addition, the application may be difficult to port to a different platform because the application control logic and state cannot be reused.

In many cases, applications contain state that must be maintained. If state is stored in a form, the code must access the form to retrieve state. This can be difficult to implement and tends to result in inelegant code, which again affects the extensibility and reusability of a user interface. For example, if, you develop several forms to be viewed sequentially, and then you need to insert a new form in the sequence, you must recode or modify both the previous and subsequent forms to incorporate the new form.

As a user interacts with an application, he or she may begin a task, put it on hold for a while, and then return to it. If the user closes the application between sessions, he or she may lose state and need to restart the entire task from the beginning. This is tedious for the user, and in some cases, it is unacceptable for your business logic.

Therefore, as you design your application, consider workflow, navigation, and interaction with business services and components as separate concerns from how data is acquired and presented to the user.

The User Interface Process (UIP) Application Block, version 2, provides an extensible framework to simplify the process of separating business logic code from the user interface. You can use the block to write complex user interface navigation and workflow processes that can be reused in multiple scenarios and extended as your application evolves. This guide describes the design and features of the UIP Application Block and demonstrates how you can use the block in your applications.

The UIP Application Block addresses a specific set of challenges that you will encounter in user interface development. These include:

• Navigation and workflow control — This should not be embedded in the user interface, but often is because the decision about which view to display next is based on business logic. This results in inelegant and unmanageable code.
• Navigation and workflow changes — Reformatting the layout of an application (changing the sequence of pages or adding new pages) is very difficult with traditional user interface techniques.
• State management — Passing state and maintaining consistency of state between views is difficult and is different for Windows-based applications and Web applications.
• Saving a snapshot of current interaction — You may want to capture a snapshot of an interaction and recreate it elsewhere, across time, machine, or logon boundaries.

Who Should Read This Guide

This guide is targeted at software developers and architects who are developing applications with complex user interface interactions. Specifically, the target customer for the block is a developer who designs and writes code to create Web applications or applications designed to run on the Microsoft® Windows® operating system (including smart client applications).

Prerequisites

To fully benefit from this guide, you should have an understanding of the Microsoft .NET Framework (including .NET Framework security concepts). The specific technologies mentioned in the guide are the Microsoft Visual C#® development tool, the Microsoft Visual Basic® .NET development system, the .NET Framework, and XML.

User Interface Process Concepts

To help manage the presentation layer in your application, you should split it up into manageable units. A number of terms related to this concept are heavily used in this guide. These include:

• A user interface process — A set of user-related activities that achieve a goal. By grouping together activities in this way, you can define the views that are used in each user interface process and determine how navigation should occur between those views.
• A UIP task — A running instance of a user interface process.
• UIP state — A snapshot of a task that can be persisted.

These terms, along with other important UIP-related terms, are discussed in more detail in Appendix B, "UIP Application Block Terminology."

The UIP Application Block allows you to abstract the presentation layer code of your application into a separate layer. Applications that use the UIP Application Block have a presentation layer that is further divided into the following layers:

• User interface components — These components make up the user interface of the application. Users see and interact with these components. User interface components are responsible for acquiring data from the user and rendering data to the user.
• User interface process components — These components orchestrate the user interface elements and coordinate background activities, such as navigation and workflow control and state and view management. Users do not see user interface process components; however, these components perform a vital supportive role to user interface components.

The following diagram shows these two layers in the architecture of a .NET-based distributed application.

Figure 1.1: Component layers found in distributed applications and services built with .NET

The UIP Application Block is a framework for building user interface process components. These components are responsible for:

• Managing the flow of information through the user interface components
• Managing the transitions between stages of a user interface process
• Modifying user process flow in response to exceptions
• Separating the conceptual user interaction flow from the implementation or device where it occurs
• Maintaining internal business-related state, usually by holding on to one or more business entities that are affected by the user interaction

This means they also manage:

• Accumulating data taken from many UI components to perform a batch update at the server
• Keeping track of the progress of a task in a user interface process

By keeping your user interface process components separate from your user interface components, you can abstract the code that controls the underlying behavior of the application from the user interface itself. This allows you to write reusable code for the control flow and state management of different types of applications, independent of the user interface used. It also allows you to change user interfaces and manage multiple user interfaces without changing large amounts of code and gives you more flexibility in testing your applications because you can split test procedures into logical units independent of the user interface.

Model-View-Controller

The UIP Application Block is based on the model-view-controller (MVC) pattern. This is a fundamental design pattern for the separation of user interface logic from business logic. The pattern separates the modeling of the application domain, the presentation of the application, and the actions based on user input into three distinct objects:

• Model — This object knows all about the data to be displayed and is responsible for managing the data and the actions of the application. It can be thought of as the processing part of an input-process-output system.
• View — This object manages the information displayed to users. Multiple views can be used to display the same information in different ways. It can be thought of as the output part of an input-process-output system.
• Controller — This object allows the user to interact with the application. It takes input from the user and passes instructions to the model. In the input-process-output system, this is the input part.

Figure 1.2 depicts the structural relationship between the three objects.

Figure 1.2: MVC class structure

Both the view and the controller depend on the model. However, the model depends on neither the view nor the controller. This is one of the key benefits of the separation. This separation allows the model to be built and tested independently from the visual presentation.

Exactly how you implement the model-view-controller pattern depends on your application type. For example, the separation between view and controller is secondary in many rich client and smart client applications, and many user interface frameworks implement the roles as one object. However, in Web applications, the separation between view (the browser) and controller (the server-side components handling the HTTP request) is very well defined.

Note   For more information about MVC, see "Model-View-Controller".

Goals of the UIP Application Block

The UIP Application Block is designed to help you:

• Abstract all navigation and workflow code from the user interface
• Enable the use of the same programming model for different types of application
• Remove all state management from the user interface
• Persist snapshot state across processes

It is useful to discuss each of these in more detail.

Abstracting Navigation and Workflow Code

The workflow of an application is a business process, not a user interface process, and the control of it should lie outside of the user interface layer. Code abstraction also helps you to maintain and extend your existing applications more easily.

The UIP Application Block abstracts workflow code from the user interface layer into the user interface process layer. As the navigation within the workflow is not hard coded into the user interface elements themselves, if the flow of your application changes, you need to recode the process only, not the elements within the process.

Using a Single Programming Model

You may create a Windows-based application for an internal audience, and later need to develop a Web-based front end for external users. You may develop applications for a Web browser that later need to be ported to a device application. If you use the same programming model for all application types, you can more easily port applications from one platform to another.

By using the UIP Application Block, you can ensure that all the navigation and workflow code is extracted from the user interface. This allows you to plug in new views (pages, forms, or whatever the application requires), and reuse the rest of the existing application.

Removing State Management From the User Interface

In many applications, state is stored in the user interface layer. This means that complex code is required to store, access, and manipulate that state. In addition, state is dependent on the user interface type, which can make it difficult to transfer code between application types.

The UIP Application Block abstracts UIP state from the user interface and stores it in a generic state object that can be accessed by using the block classes. This means that any view can work with the UIP state without knowing which other view is storing that information, or how to access it. If the view type is changed, the state management code can be left untouched.

Persisting a Snapshot of State Across Processes

In many applications, it is very difficult to store the state of a task at any given time. Most applications use transactions to encapsulate each task or sub-task, but only allow a complete transaction to either succeed or fail. This means that if a system shuts down or a user navigates away from a Web site, it is often difficult for the system or user to return to the point at which they left that process.

The UIP Application Block includes state persistence mechanisms that allow code to persist UIP state. This allows you to develop applications that persists UIP state at pre-determined intervals, meaning that you can restore the application at a later time. In addition to storing state in the application's memory, your code can save it in isolated storage or a database for later reuse.

Note   The UIP Application Block was designed based on reviews of successful .NET applications. It is provided as source code that you can use as-is or you can customize the code to more closely fit your specific requirements. It can be used to solve a number of challenges presented to developers, and enhances the reusability and maintainability of your code. It is not an indication of future direction for user interface processes within the Microsoft .NET Framework. Future releases of the .NET Framework may address user interface processes using a different model.

Features of the User Interface Process Application Block

The User Interface Process Application Block provides you with a number of features that will help you develop User Interface Process Components, and therefore distributed applications, more efficiently. The following features were in the first version of UIP and continue to be part of UIP version 2.

• Web session resume — Allows users to save information in a browser, so that next time they start a browser session, they can continue from where they left off.
• Web session transfer — Helps one user to suspend a session, and another user to pick it up on another computer. Also allows you to suspend a session on one device, and resume it on a different type of device.
• Reuse of code between application types — Helps you port the user interface process control logic from one type of application to another (for example, from a Windows application to a Web application).
• Development of discrete tasks — Helps you develop encapsulated tasks (for example, a Register User task and a Checkout task) that can be linked together to complete a job. You can pass information between tasks as required (for example, you can pass user details to the Checkout task).
• State persistence providers — Allows you to store and retrieve state from a SQL Server database, Web Session object, or from memory.

The following features are new to UIP version 2:

• Expanded navigation management — Gives you a variety of options for specifying the transitions between views in Windows-based applications and Web applications. Each navigator provides a different level of locking the user into the pre-defined flow of transitioning between views. In the previous version of the UIP Application Block, navigation management was provided solely by the navigation graph. In UIP version 2, the navigation graph is one of several navigation options.
• Additional state persistence providers — Gives you the ability to store and retrieve state from isolated storage and gives you the option to encrypt the data.
• Layout Managers — Gives you the ability to add custom layout logic to views in your applications
• User Navigation management — Uses conditional logic to test whether the user is allowed to navigate to a view by specifying a URL or by clicking on the back or forward buttons.
• Usability enhancements — Helps you with debugging, provides an extensible UIP schema, and provides a shared view for common transition points.

Several QuickStarts are included in the download of this block. You can use the QuickStarts to familiarize yourself with the functionality of the block. For more information about QuickStarts, see the section, "QuickStarts for the UIP Application Block," in Chapter 3, "Developing Applications with the UIP Application Block."

Chapter Overview

The remainder of this guide consists of the following chapters.

• Chapter 2, Design of the UIP Application Block — To make the most of the UIP Application Block, you need to understand its design. Chapter 2 discusses the architecture of the block.
• Chapter 3, Developing Applications with the UIP Application Block — After you understand the design of the UIP Application Block, you can start developing applications with it. Chapter 3 explains the process for building the block and modifying your application to use the block. The chapter also discusses the QuickStarts provided with the block.
• Chapter 4, UIP Application Block Deployment and Operations — After you create applications that use the UIP Application Block, you will need to deploy them. Chapter 4 discusses the special considerations for deploying these applications, including prerequisites for deployment and security threats and countermeasures.
• Appendix A, Extending the UIP Application Block — Using the UIP Application Block in a default configuration works well in most situations. However, there are times when you may want to customize certain parts of the block to be more specific to your needs. Appendix A provides guidance on extending the functionality of the block to develop your own state management class, custom state persistence providers, custom view implementations, and custom task implementations.
• Appendix B, UIP Application Block Terminology — This appendix will help you understand many of the concepts and terminology used in the UIP Application Block and in this guide.

If you are interested in evaluating the UIP Application Block, Chapters 1 and 2 and Appendix B are most useful. If you have decided to incorporate UIP in your application or if you are already using the previous version of the block and want to upgrade to this version, Chapters 2, 3, and 4 are valuable. If you already have a good understanding of developing with UIP and want to extend the functionality of the block, Appendix A will help you.

Conclusion

The User Interface Process (UIP) Application Block, version 2, is based on the model-view-controller (MVC) pattern, and provides an extensible framework you can use to simplify the process of separating business logic code from the user interface. The block will help you write complex user interface navigation and workflow processes that can be reused in multiple scenarios, and extended as your applications evolve. The remainder of this guide describes the design and features of the block and demonstrates how you can develop your applications to take advantage of the functionality of the block.

Start | Previous | Next