We often write ASP.NET modules to customize ASP.NET processing pipeline - extend security, etc.
1: public class ExampleModule : IHttpModule
2: {3: #region IHttpModule Members
4: 5: public void Dispose() { }
6: 7: public void Init( HttpApplication context )
8: {9: context.BeginRequest += new EventHandler( context_BeginRequest );
10: } 11: 12: void context_BeginRequest( object sender, EventArgs e )
13: {14: // extend the processing pipeline by providing
15: // custom code for particular events, in this case
16: // the BeginRequest event
17: } 18: }However, as modules are static, in a sense that a module is active or inactive in processing pipeline, applications which "host" modules are dynamic, in a sense that different applications work under different conditions.
The issue we've faced recently was to inject a custom, application specific code into module:
1: void context_BeginRequest( object sender, EventArgs e )
2: {3: // how to call an application-defined code
4: // but do it so that the module is not
5: // rewritten everytime application changes
6: 7: // ?
8: }The solution we've came up with was rather simple: we've used a custom provider to provide application-specific code.
1: <system.web>
2: <specificProvider defaultProvider="ApplicationSpecificProvider">
3: <providers>
4: <add name="ApplicationSpecificProvider" type="Namespace.ApplicationSpecificProvider" />
5: </providers>
6: </specificProvider>
This way we can configure different providers on the application level but still be able to write generic module code:
1: void context_BeginRequest( object sender, EventArgs e )
2: { 3: HttpApplication app = (HttpApplication)sender; 4: 5: SpecificProvider.DoSpecificOperation( app ); 6: }
No comments:
Post a Comment