您应该做的是创建一个空的成员资格提供程序,它只是调用 MVC Dependency Resolver 以获取真实的Membership Provider
. 通过这样做,您可以实现三件事:
- 此实现有一个默认构造函数,可以在 web.config 中进行配置。
- 该实现是一个 MVC 基础结构组件,并且与包含该实现(您可能想要测试)的实际成员资格提供程序分离。
- 该基础设施组件不依赖于 Unity(或任何其他容器),而仅依赖于 MVC3,这降低了容器本身的耦合度。
实现可能如下所示:
public class DependencyResolverMembershipProvider : MembershipProvider
{
private static MembershipProvider Provider
{
get
{
var provider = DependencyResolver.Current.GetService<MembershipProvider>();
if (provider == null)
{
throw new InvalidOperationException(
"Make sure the MembershipProvider is registered.");
}
return provider;
}
}
public override string ApplicationName
{
get { return Provider.ApplicationName; }
set { Provider.ApplicationName = value; }
}
public override bool ChangePassword(string username,
string oldPassword, string newPassword)
{
return Provider.ChangePassword(username, oldPassword, newPassword);
}
public override bool ChangePasswordQuestionAndAnswer(string username,
string password, string newPasswordQuestion, string newPasswordAnswer)
{
return Provider.ChangePasswordQuestionAndAnswer(username,
password, newPasswordQuestion, newPasswordAnswer);
}
public override MembershipUser CreateUser(string username,
string password, string email, string passwordQuestion,
string passwordAnswer, bool isApproved, object providerUserKey,
out MembershipCreateStatus status)
{
return Provider.CreateUser(username, password, email,
passwordQuestion, passwordAnswer, isApproved, providerUserKey,
out status);
}
// Implement all other methods here
}
这仍然是很多工作,因为它MembershipProvider
有很多方法。有两种方法可以使这更容易:
- 使用Griffin.MvcContrib之类的框架,它已经为您完成了这样的事情,并且以一种更愉快的方式完成,因为它分离了这些类内部的职责并公开了一些您可以为此功能实现的新接口.
- 防止系统的任何部分依赖于静态
Membership
类,但始终将 a 注入MembershipProvider
到这些类中,甚至更好:不要使用 the ,MembershipProvider
而只需注入可能在其后面的接口MembershipProvider
(例如IUserRepository
and IPasswordManager
)。