WCSF: HTTP module problem

Topics: Web Client Software Factory, User Forum
Mar 21, 2009 at 5:52 PM
Hello

I have a problem creating an HTTP module that handles the PreRequest HTTP event in my WCSF application.

My HTTP module, ServerTransferModule, needs to have a access to one of my WCSF foundation modules, DataAccessServices. I tried creating a class that inherits IHttpModule in App_Code in the usual way and added a dependency to DataAccessServices. Of course, the service dependency is never injected because the WCSF isn't interested in the class.

So, I tried to implement the IHttpModule in my ShellController class, which kinda works, but of course because the HTTP module event handler is for the pre-request, the handler executes before any of the dependencies in ShellController are injected, so DataAccessServices isn't available.

Anyone have an idea for a good strategy to deal with this? I could hack it around but I don't want to go needlessly creating inter-class dependencies.

Regards, Mark


Mar 23, 2009 at 7:47 PM

Hi Mark,

HTTP modules are instantiated and managed directly by ASP.NET and WCSF does not realize that these were created and are running.

For this reason, the HTTP modules do not go through the ObjectBuilder’s pipeline. So, for example, the different properties decorated with the [ServiceDependency] attribute will not be assigned to with the required services.

 

A possible workaround could be passing HTTP Modules thought the ObjectBuilder’s pipeline manually. You can do this calling the BuildItemWithCurrentContext method (defined in the WebClientApplication class) in the HTTP module’s constructor as it is shown in the following example:

 

public class ServerTransferModule: IHttpModule

{

    public ServerTransferModule()

    {

WebClientApplication.BuildItemWithCurrentContext(this);

    }

 

    //Your code…

}

 

If you have a lot of HTTP modules, a good idea could be creating a base class that implements the IHTTPModule interface and calls the BuildItemWithCurrentContext method in its constructor. Then, your HTTP Modules only have to inherit from that class to be able to access to the different services.

 

Please, let me know if this helps.

 

Ezequiel Sculli

http://blogs.southworks.net/esculli/
Mar 23, 2009 at 9:38 PM
Hi Ezequiel

Thanks again for responding.

As it turns out, I only really need to make one call to the database so I decided just to call the DataContext object directly. I know that in reality this compromises the integrity of the MVCP and service dependency patterns but I'm not so worried for just one call. If I find myself doing this sort of thing more frequently in my application, then I'll probably look into the BuildItemWithCurrentContext() method as you describe.

I really ought to take a look at the source code for the composite application block because I don't really understand how it works internally but my limited understanding seems to be enough to implement a web client software factory pattern. Microsoft, I understand, have just released a MVP pattern for ASP.NET applications that I might look into because I'm not convinced my application meets the criteria for a WCSF application as described in the documentation. The only reason I chose to use it was because it was the first guidance package I'd come across that implemented the mode-view-presenter pattern, so perhaps this latest Microsoft release might be more appropriate. Maybe WCSF is a bit of overkill...

Thanks again!

Regards, Mark