User Interface Process Application Block (UIPAB)

Introduction

Microsoft application blocks are put up by the Pattern and Practices group of Microsoft. UIPAB is one of those infrastructural areas which are being addressed as higher level issues and needs to be resolved. Though .NET Framework provides sets of core services, to make our application more scalable, maintainable and also reusable, we need application blocks. I will be trying to summarize the UIPAB in a two article series. This is the first article of the series, which contains a brief description of UIPAB and some of the keywords used in UIPAB. My second article will go in depth into UIPAB with a demonstration.

User Interface Process Application Block

Microsoft application blocks are put up by the Pattern and Practices group of Microsoft. There are many blocks that got released till now, the first one being the data access block and then a series of other blocks have been released. Now if we look at the typical implementation of the navigation links that are coded in the application, we get to know that navigation flows, workflow logic and state management are tightly coupled with the views. The problem arises when there is a need to change a view or a new view is to be inserted between two existing views. We need to change at all places which makes navigation code hard to maintain and debug. So if we look at the user interface design challenges, they can be summarized as:

1. Provide navigation from view to view.
2. Provide required state to each view.
3. Provide coupling between individual views.

The best implementation is that where each view can know how to initialize itself, load a state if any present, and also contain some other relevant information rather than knowing about states of other views. To address these kind of scenarios, we have a design pattern known as Model View Controller (MVC) designer pattern. What it does is that it divides your presentation layer into three conceptual objects namely model, view and controller. This MVC can be thought of as the IPO cycle where Model is the processing part and encapsulates any state or logic for the application. It is everything that drives your application but doesn’t affect the presentation directly. View is a pure UI and it takes the data from the user and shows or renders data to the user so view can be your web form, web page and even your Window Form. Controller is the negotiator or middle man between the Model and View. It handles the navigation and figures out how to make the transition from view to view.

Now as far as UIPAB is concerned, it is basically a .NET implementation of MVC. So in case you are building an application on .NET, you can use the UIPAB to implement the presentation tier based on MVC in a very scalable way. Advantage is that it can work in both Windows and web applications. All the application blocks show some common attributes in which one is that they are all extensible. If you want to use any of the application blocks in your application, you have to put it in the configuration file and it is how you plug your block into the application, and they are customizable even in a dynamic environment. If you install an application block, you will get the source code which you need to compile in order to generate the assembly. This assembly is to be used in other applications which are required to integrate UIPAB in them. So compile and reference the assembly from Web or Windows applications like any other assembly reference. After knowing about UIPAB and why it is used and what it does, we should now get familiar with the terminology used in UIPAB.

View

is an abstract term that basically says it provides user interaction with a single screen of information and can be a web page, web form or a Windows form. A key aspect of view is it does not know anything about other views in the application. All it knows is the controller, and while implementing the view in UIPAB, we have to inherit our view with WindowsFormView or WebFormView.

Controller

maps directly with the Controller of the MVC pattern and it controls all the navigation in the application. It controls access to the state from the view. This state is the state between views and works only in the presentation tier. So if there are more than one view and you need to persist the state between the views, you have to use Controller. Even if you want to persist the state with business logic and data access layer, you need to use controller to do the things. Controller provides a link between the presentation layer and the business logic layer. If you want to make a controller in your application, you have to create a class which derives from the ControllerBase class.

Tasks

Task is a logical boundary between a set of views that signifies that those views are related to each other and achieve one common task or workflow. So UIPAB not only decouples views but also ties the views in a workflow like scenario. You can assume it as the Use Case implementation of views. So you can have a few views that share the state with each other and are separated from other views so the collection of the views can be identified by giving the taskID to the task. Tasks also define the navigation between the views, and state gets associated with the task through the controller.

State

State represents where the tasks is in the process. State is associated with the task, managed through the controller, and accessible to the views for presentation.

If you look at the application, it contains the blocks of various applications.

Now all those blocks that are in the lighter yellow color like WebForm, WinForm, Controller, State Objects are what we need to provide as part of the application. Once we write these things, then we can work with UIPAB. Darker yellow color containing View Manager, UIP Manager, Session are those parts that are either pre-coded or available to your application. So you are using this in your application directly or indirectly. Darker grey color boxes like State Persistence Provider, Custom State Provider and Custom State Store depict the extensibility point of view. These things are already provided in UIPAB but in case they didn’t fulfill your requirements, you can build your own state stores. Memory and sessions are state stores that ship with the blocks and SQL Server is the state store that is out process. Now there is some more storage that has come in version 2.0 which includes isolation storage, encrypted version of isolated storage, and state storage. Now there is also a navigator object between the UIP Manager and View Manager. In version 2.0, there is support for multiple navigation model, it is not accessed directly.

How it works?

We create our Windows or Web Forms and derive those from the base classes which are the part of UIP. Since we are deriving them from the base class, we can directly access the controller class through a base class reference. Now controller is what we need to make which again derives from ControllerBase class. From the Web or Windows Forms, we will be calling the abstract navigation methods like ShowNext and ShowPrevious of the controller. These are called as abstract navigation methods as by looking on these methods, we cannot figure out which is the next form to be called and then the controller depicts out which form is calling it and what configuration file is saying it to be the next view. Forms also access state through the controller. State can be stored in as simple as a hash table or the custom state blocks. Now the main thing that drives everything is the config file which looks very complex, but it is fairly straightforward. It is this config file which contains information that the UIP Manager looks at for pointing out which is the next view to get called. In case we have the middle tier or middle layer, we have the controller who interacts with this tier and works.

Conclusion

I hope this article has given some general introduction about the use of UIPAB. In the next article, I would be going in depth of the UIPAB with some demos. Hope you have liked this article.