asp.net 中的提供程序设计模式
我需要一些有关 DLL 架构/设计模式/面向对象的帮助。
我一直在学习类工厂设计模式 我当前挑战的解决方案,可以使用一些反馈 在此刻。
我有三个类,它们是 ASP.NET 2.0 的自定义包装器 ProfileProvider、MembershipProvider 和 RoleProvider。
我想实现一种合理调用每个方法的方法 对于开发人员来说简单直观。其效果是:
Object obj = new Users().Permissions.CreateRole();
Object obj = = new Users().Membership.CreateUser();
Object obj = = new Users().Profile.GetUserProfile();
我读过的有关如何使用抽象类执行此操作的示例 工厂(如果确实是这样的话)有点令人困惑 (我一直在此链接)。
关于如何开始的最佳实践有什么建议吗? 或者,更好的是,代码插图? :)
I need some help with DLL architecture / design patterns / OO.
I have been learning about class factory design patterns as a
solution to my current challenge and could use some feedback
at this point.
I have three classes that are custom wrappers for ASP.NET 2.0's
ProfileProvider, MembershipProvider, and RoleProvider.
I'd like to implement a way of calling each that is reasonably
simple and intuitive for developers. Something to the effect of:
Object obj = new Users().Permissions.CreateRole();
Object obj = = new Users().Membership.CreateUser();
Object obj = = new Users().Profile.GetUserProfile();
The examples I have read on how to do this using an abstract class
factory (if, indeed, this is the way to go) are somewhat confusing
(I have been working my way round this link ).
Any suggestions on best practices as to how to get started?
Or, even better, code illustrations? :)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
成员资格提供程序类的 API 非常简单,我认为包装它们不会带来太多好处。我认为您正在寻找的是 外观模式。基本上,您将创建一个类来封装应用程序的用户管理活动并隐藏内部实现。对该类的调用可能如下所示:
UserService 类将使用成员资格提供程序来创建新用户并为其分配管理员角色。
The APIs for the membership provider classes are pretty straightforward and I don't think there's much to be gained by wrapping them. I think what you're looking for is the facade pattern. Basically you would create a class that encapsulates the user management activities for your application and hides the internal implementation. Calls to the class might look like:
the UserService class would use the membership provider to create a new user and assign the admin role to them.
在我看来,您在抽象之上创建抽象,没有任何实际目的,也没有真正的好处。我对 ASP.NET 提供程序的实现方式(为了可测试性)有疑问,但我用另一种方式解决了这个问题。
我所做的是创建一个类来包装 MembershipProvider 并实现一个接口。它所做的只是将方法调用传递给 MembershipProvider,但它允许我依赖接口而不是实现。在我的测试中,我可以将 IMembershipProvider 替换为模拟版本。
编辑示例代码:
IMembershipService
和 IMembershipUser
以及 ASP.NET 提供程序的简单包装器:
和 MembershipUser
非常简单的实现,但您可以使用它。
It looks to me that you're creating an abstraction on top of an abstraction for no real purpose and with no real benefit. I have issues with the way ASP.NET Providers were implemented (for testability), but I addressed that in another way.
What I did was create a class that Wrapped the MembershipProvider and implemented an interface. All it does is pass methods calls to the MembershipProvider, but it allows me to rely on the interface instead of the implementation. In my tests, I can swap out IMembershipProvider for a mocked version.
edit, sample code:
IMembershipService
and IMembershipUser
and a simple wrapper for ASP.NET provider:
and MembershipUser
Very simple implementation, but you can go to town with it.