Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

How To Create a Custom Policy Injection Application Block Handler : Page 6

Using custom policy injection, you can configure and apply policies exactly the way you want—but doing it right requires a little effort.


advertisement
Editing the Application Configuration
The built-in VS2005 Configuration Editor and the default Enterprise Library Configuration Console will not work directly with applications that use unsigned versions of the Enterprise Library assemblies located in the Bin folder. Instead, you can use the version of the Configuration Console in your EntLibSrc folder, or change the behavior of the VS 2005 Configuration Editor to use the unsigned assemblies in your EntLibSrc folder rather than the signed assemblies in the Program Files folder. To change the behavior of the VS 2005 Configuration Editor:

  • Use the File menu to add a new Web Site to the project so that VS creates a root-level solution node containing the two projects.
  • Select the solution node and open the Properties window by pressing F4.
  • Change the EnterpriseLibraryConfigurationSet property to EntLib3Src, and click OK in the warning dialog.
  • Select "Save <solution-name> As" from the File menu and save the solution file in the project folder.
  • Select the project node for the new Web Site project you added, right-click, and select Remove.
  • Select Save All from the File menu.
  • Use the saved solution file (.sln) to open the project in future.
The example files for this article contain suitable solution files that you can use to open the projects with the appropriate configuration setting for the VS2005 Configuration Editor.

The ASP.NET Page in the Example Application
The ASP.NET page Default.asp and the associated code-behind file (provided in both C# and VB.NET in the downloadable code) provide buttons to call the methods of the DemoClass object and display the return value in a Label control. For example, here's the code that runs when you click the first button in the page to get the current weekday name:

protected void btn_WeekdayName_Click(object sender, EventArgs e) { try { DemoClass target = PolicyInjection.Create<DemoClass>(); lblResult.Text = target.GetCurrentWeekday(); } catch (Exception ex) { lblResult.Text = "ERROR: " + ex.Message; } }

Notice that the code handles any error that may arise. The NeverOnASunday handler will raise an exception if it detects invocation on a Sunday (or a Saturday if the NotSaturdayEither property is true). Figure 3 shows the simple example page.

 
Figure 3. Example Page: Here's the ASP.NET example page, showing the result of calling the GetCurrentWeekday method of the DemoClass object.
 
Figure 4. Tracing Handler Calls: Here's the pertinent trace information generated by calling the NeverWorksOnSunday method on a weekday.
Viewing the Results of the NeverOnASunday Handler
Of course, seeing the results of the target object members executing is fine, but to test the handler and understand what is really happening you need more information about the invocation. The example ASP.NET page has tracing enabled in the @Page directive. Therefore, each time you execute one of the methods of the DemoClass object, you can view the trace information to see the values inserted by the code in the NeverOnASunday handler.

For example, Figure 4 shows the section of the trace information that contains the output generated by the handler when you call the NeverWorksOnSunday method on a weekday (in this case, Tuesday). You can see the target object name, the method name, the single parameter name and its value, and the return value.

If you run the application on a Saturday and a Sunday (or just change your system's date appropriately) you can experiment to see the effects of the NeverOnASunday handler when it prevents invocation of members of the target class.

Figure 5 shows the example application running on a Sunday, where a call to the NeverWorksOnSunday method fails and the page displays the message contained in the Exception that the Policy Injection Application Block returns.

 
Figure 5. No Sunday Execution: The exception returned when calling the NeverWorksOnSunday method on a Sunday.
 
Figure 6. Tracing Information from Sunday: The trace information generated by calling the NeverWorksOnSunday method on a Sunday.
If you examine the trace information in this case (see Figure 6), you can see that the handler executed the pre-processing code that displays details of the invocation message. It does not, of course, display any return value because the handler short-circuits and the post-processing code does not execute.

Notice as you experiment with the example that the NeverOnASunday handler is activated for every method/property of the target object except for the AlwaysWorksOnSunday method. When you call this method, irrespective of the current day and the fact that the NotSaturdayEitherPolicy configuration Policy selects this method, there are no entries in the trace information. This is because the code for this method within the DemoClass object carries the [ApplyNoPolicies] attribute.

Conversely, neither of the Policies in the example application configuration selects the AlwaysWorksOnSunday method, yet it always has a pipeline containing the NeverOnASunday handler—on both Saturday and Sunday. This is because the code for this method within the DemoClass object carries the custom handler attribute [NeverOnASundayCallHandlerAttribute(true)].

Now, Build Your Own
In this article, you have seen how the Policy Injection Application Block uses call handlers within the pipeline it creates between client code and a target object. You have also seen how easy it is to create custom handlers that implement the behavior you require for your own applications. The articles discusses the requirements for a handler, the basic implementation, and the techniques for more complex interaction with the invocation input and output messages.

The Policy Injection Application Block is a powerful tool that allows you to specify Policies through configuration, or through the use of attributes applied directly to classes and class members. This article shows how you can create custom handler attributes that developers can use to apply your custom handler within their code.

To make it easy to use custom providers, such as handlers for the Policy Injection Application Block, you can take advantage of the extensible configuration system in Enterprise Library. By creating suitable configuration node classes, and modifying the registration process, your custom handler becomes available as a standard configuration option within the Enterprise Library Configuration Console and the Visual Studio 2005 Configuration Editor.

Finally, this article demonstrates how you can use a custom handler and its related handler attribute in a simple ASP.NET application, and view its effects. I urge you to download the sample code, and experiment with it. For more information about Enterprise Library 3.0, see. http://www.codeplex.com/entlib/.



Alex Homer is a director of Stonebroom, Ltd., a software development, consulting, and training organization. He was formerly lead technical author and reviewer for Wrox, specializing in Microsoft Web and database technologies. You can reach him through his Web site.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap