ASP.NET 或 DotNetNuke 成员资格的用户创建事件答案

【问题标题】：user creation event for ASP.NET or DotNetNuke membershipASP.NET 或 DotNetNuke 成员资格的用户创建事件
【发布时间】：2009-04-08 22:48:56
【问题描述】：

我想添加一些在新用户在 DotNetNuke 站点上注册时运行的代码。有一个自定义注册模块，我可以向其中添加代码。我担心的是这个注册模块仍在进行中，这不是我能真正控制的。有人可能会破坏我添加的代码或做一些意想不到的事情。

我可以使用向用户会员活动添加代码的另一种好的选择吗？

我正在考虑创建一个派生自我们现有提供程序的成员资格提供程序（DNN 或 ASP.NET 提供程序）。我将扩展 CreateUser() 的实现以调用原始实现，然后调用我的自定义代码。

好处是它们与注册组件没有耦合。不利的一面是——与添加配置独立于站点其他方面的 HttpModule 不同——我将隐藏现有的成员资格提供程序。假设有人出于其他原因想要更新提供程序 - 他们将不得不重新编译我的类，而不是能够简单地更改 web.config 文件。

我打算创建一个派生自 MembershipProvider 的泛型类，然后使用原始提供者作为泛型类型参数。我希望这会希望将原始提供程序类型包含在 web.config 定义中。不幸的是，C# 泛型不允许您从泛型类型参数派生。 :(

【问题讨论】：

【解决方案1】：

如果您从现有的成员资格提供程序派生，为什么在另一个提供程序更改时必须重新编译您的类（假设您没有使用强名称引用）？提供者模型的整个想法是合同不会改变。对基本会员提供者的任何更改都将是内部的，因为合同必须保持不变。您的提供者也必须这样做，因此它也可以被覆盖。如果您的提供商只是这样做：

class NewMembershipProvider : ExistingMembershipProvider

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

您已经清晰地抽象了实现细节。一个人可以改变而不影响另一个人。未来的任何更改都可以通过覆盖您的提供程序来实现。

【讨论】：

【解决方案2】：

我强烈认为您可能会在这里增加一些复杂性。事物总是可以以任何形式打破，很难做到“不耦合”。尝试编写一些好的单元测试用例，以便您知道它们何时被破坏，而不是创建一个完全不同的处理程序来创建新用户。

【讨论】：

添加测试是个好主意，但我不确定哪种测试可以解决这个特定问题。看来我需要一个贯穿网站注册过程的集成测试，因为我要验证的是 web.config 设置没有被破坏。
我认为你是对的，尽管我们总是受限于我们可以做多少去耦。不过，在这种情况下，我想做的事情（处理用户成员资格事件）似乎可以自然而然地实现，我希望我只是忽略了一个选项。