Login | Register   
LinkedIn
Google+
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 5

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


advertisement
Implementing the NeverOnASundayCallHandlerAttribute
At this point, you can configure your applications to use the new handler by editing the configuration files manually or with the Enterprise Library configuration tools, but you can't add the new handler with a code attribute. Before looking at how you can use the new handler in an ASP.NET application, it's worth considering creating a handler attribute that developers can use to add the handler to a class, method, or property at design-time. This is useful when a developer wants to set the behavior of an object and ensure that specific handlers always execute, irrespective of the current configuration of the Policy Injection Application Block.

A handler attribute simply has to generate an instance of the relevant handler class, and set any properties for which the attribute specifies values. Usually, the attribute will expose the same properties as the handler, and pass the values through to the handler.

The HandlerAttribute base class provides much of the implementation required for a handler attribute. All your attribute class must do is provide the required constructors, and implement the CreateHandler method that returns a configured instance of the appropriate handler.

For the NeverOnASunday handler, the file NeverOnASundayCallHandlerAttribute.cs (in the App Blocks\Src\PolicyInjection\CallHandlers subfolder of the Enterprise Library source code) implements a suitable handler attribute. Once again, if you're editing the existing Enterprise Library project, you must ensure that you place the class in the correct namespace (Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers), and add using statements for the other namespaces required. The sample project contains the complete file.

The following listing shows the attribute class. Notice the AttributeUsage attribute that specifies where the developer can use this handler—in this case on a class, a method, or a property. The class also contains two constructors. The first constructor sets the value of the private notSaturday variable to the default value of the NotSaturdayEither property using the public DefaultNotSaturdayEither field exposed by the NeverOnASundayCallHandler class. The second constructor sets the value to that passed to the constructor from the attribute on the target member:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Property | AttributeTargets.Method)] public class NeverOnASundayCallHandlerAttribute : HandlerAttribute { private Boolean notSaturday; public NeverOnASundayCallHandlerAttribute() { notSaturday = NeverOnASundayCallHandler.DefaultNotSaturdayEither; } public NeverOnASundayCallHandlerAttribute(Boolean notSaturdayEither) { notSaturday = notSaturdayEither; } public override ICallHandler CreateHandler() { return new NeverOnASundayCallHandler(notSaturday); } }

The remaining code is the CreateHandler method that simply generates a new instance of the NeverOnASunday handler, specifying the value for the NotSaturdayEither property. This is all that is required to create a handler attribute.

Rebuilding Enterprise Library
After all the new and updated code is in place, you must recompile the Policy Injection Application Block and the configuration tools. In fact, the easiest way is to use the BuildLibraryAndCopyAssemblies.bat utility installed by default in your EntLibSrc\App Blocks folder. This recompiles the entire Enterprise Library, and copies all the assemblies and the configuration tools to the EntLibSrc\App Blocks\Bin folder, so it's ready for use.

Using the NeverOnASunday Handler in ASP.NET
Finally, this article demonstrates how you might use the new custom NeverOnASunday handler and the matching handler attribute in a simple ASP.NET application. Create a new Web Site and a suitable target object, or open an existing Web site or application that contains a suitable target object. The object must either inherit MarshalByRefObject, or have an interface definition available. The sample application contains an example of an object named DemoClass, which inherits from MarshalByRefObject, and exposes three methods and a property:

  • The GetCurrentWeekday method, which returns the name of the current weekday:
  • public String GetCurrentWeekday() { GregorianCalendar cal = new GregorianCalendar(); return cal.GetDayOfWeek(DateTime.Now).ToString(); }

  • The AlwaysWorksOnSunday method, which returns a message that—depending on the value of the returnWeekday parameter—can include the current weekday name. Notice that this method carries the [ApplyNoPolicies] attribute, which always prevents the Policy Injection Application Block from generating a handler pipeline for this member:


  • [ApplyNoPolicies] public String AlwaysWorksOnSunday(Boolean returnWeekday) { String returnValue = "Yes, I am working today"; if (returnWeekday == true) { GregorianCalendar cal = new GregorianCalendar(); String dayName = cal.GetDayOfWeek(DateTime.Now).ToString(); returnValue += ", even though it's " + dayName; } return returnValue; }

  • The NeverWorksOnSunday method, which is the same as the AlwaysWorksOnSunday method but carries an instance of the custom handler attribute [NeverOnASundayCallHandlerAttribute] that sets the value of the NotSaturdayEither property to true:
  • [NeverOnASundayCallHandlerAttribute(true)] public String NeverWorksOnSunday(Boolean returnWeekday) { String returnValue = "Yes, I am working today"; if (returnWeekday == true) { GregorianCalendar cal = new GregorianCalendar(); String dayName = cal.GetDayOfWeek(DateTime.Now).ToString(); returnValue += ", even though it's " + dayName; } return returnValue; }

  • The GetTodaysDate property, which returns the current date and time:
  • public DateTime GetTodaysDate { get { return DateTime.Now; } }

 
Figure 2. Sample Application Configuration: The figure shows the configuration of the sample application in the Visual Studio 2005 Configuration Editor.
Now use the configuration tools to add the Policy Injection Application Block to the application, and configure Policies that match members of the target object—with each Policy using one or more Matching Rules. Then add the NeverOnASunday handler to the Handlers section of each Policy. The example code for this article has the configuration already set up, though you can edit it as required. Figure 2 shows the default configuration open in the Visual Studio 2005 Configuration Editor.

From Figure 2, you can see that the example application uses two policies, each with a Type Matching Rule that selects the DemoClass object and a Matching Rule that selects members of the DemoClass object:

  • The NotSaturdayEitherPolicy selects the GetCurrentWeekday and the AlwaysWorksOnSunday methods using a member Name Matching Rule, and applies the NeverOnASunday handler with the NotSaturdayEither property set to true.
  • The SaturdayOKPolicy selects the GetTodaysDate property, and applies the NeverOnASunday handler with the NotSaturdayEither property set to false.
Note that neither of these policies applies the NeverOnASunday handler to the NeverWorksOnSunday method.



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap