ASP.NET 或 DotNetNuke 成员资格的用户创建事件
我想添加一些在 DotNetNuke 网站上注册新用户时运行的代码。 有一个自定义注册模块，我可以向其中添加代码。 我担心的是这个注册模块仍在进行中，并不真正在我的控制范围内。 有人可能会破坏我添加的代码或做一些意想不到的事情。
是否有另一个好的替代方案可以使用添加代码到用户会员资格活动？
我正在考虑创建一个派生自现有提供程序的会员提供程序（DNN 或 ASP.NET 提供程序）。 我将扩展 CreateUser() 的实现来调用原始实现，然后调用我的自定义代码。
优点是它们不与注册组件耦合。 但缺点是，与添加 HttpModule 不同，其中配置独立于站点的其他方面，我将隐藏现有的成员资格提供程序。 假设有人出于其他原因想要更新提供程序 - 他们必须重新编译我的类，而不能简单地更改 web.config 文件。
我打算创建一个派生自 MembershipProvider 的泛型类，然后使用原始提供程序作为泛型类型参数。 我希望这会希望原始提供程序类型包含在 web.config 定义中。 遗憾的是，C# 泛型不允许从泛型类型参数派生。 :(
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. :(
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您从现有的成员资格提供程序派生，为什么当另一个提供程序更改时必须重新编译您的类（假设您没有使用强名称引用）？ 提供者模型的整体思想是合同不会改变。 对基础会员提供商的任何更改都将是内部的，因为合同必须保持完整。 并且您的提供者也必须执行相同的操作，因此它也可以被覆盖。 如果您的提供商只是这样做：
您已经清楚地抽象了实现细节。 一个可以改变而不影响另一个。 未来的任何更改都可以通过覆盖您的提供商来实现相同的目的。
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:
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.
我强烈地感觉到你可能会在这里增加一些复杂性。 事物总是可能以任何形式破坏，很难实现“无耦合”。 尝试编写一些好的单元测试用例，这样您就可以知道它们何时被破坏，而不是为创建新用户而创建一个完全不同的处理程序。
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.