user creation event for ASP.NET or DotNetNuke membership

Question

I want to add some code that runs when a new user is registered on a DotNetNuke site. There is a custom registration module, and I could add code to that. My concern is this registration module is still a work in progress thats not really in my control. Someone could break the code I add or do something unexpected.

Is there another good alternative I can use add code to user membership events?

I'm consider creating a membership provider (either a DNN or ASP.NET provider) that derives from our existing provider. I would extend the implementation of CreateUser() to call the original implementation then my custom code.

The upside is that their is no coupling with the registration component. The downside though- unlike adding an HttpModule where the configuration is indpendent of other aspects of the site- is I will be hiding the existing membership provider. Suppose someone wants to update the provider for another reason- they would have to recompile my class instead of being able to simply change the web.config file.

I was going to created a generic class that derives from MembershipProvider, then use the original provider as the generic type parameter. I was hoping this would like the originaly provider type be included in the web.config definition. Unforuntately C# generics don't allow you to derive from a generic type parameter. :(

Answer 1

If you derive from the existing membership provider, why would your class have to be recompiled when another provider changes (assuming you're not using strongly-named references)? The whole idea of the provider model is that the contract doesn't change. Any changes to the base membership provider would be internal, since the contract must remain intact. And your provider must do the same, so it can be overridden as well. If your provider simply does:

class NewMembershipProvider : ExistingMembershipProvider

override CreateUser()
{
    //do custom stuff
    base.CreateUser();
}

You've cleanly abstracted the implementation particulars. One can change without affecting the other. And any future changes can do the same by overriding your provider.

Answer 2

I strongly feel that you may be adding some complexity here. Things can always break in any form, it is very hard to achieve 'no coupling'. Try to write some good unit test cases so you are aware when they are broken instead of creating a whole different handler for just creating new user.