自定义会员提供程序是真正值得遵循的东西吗?

本文关键字:值得 程序 自定义 | 更新日期: 2023-09-27 18:17:13

经过长时间的尝试得到我的问题的答案"我应该编写自定义MembershipProvider实现还是制作自己的自定义系统?"在SO上,我决定采用MembershipProvider的方式并开始编写我的会员提供程序并不是那么糟糕。但当时我觉得有些麻烦。

例如,在我的系统中没有用户名。电子邮件是用户名。所以CreateUser方法应该是这样的:

public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
{
    bool userExists = GetUser(email);
    if (userExists) {
        status = MembershipCreateStatus.DuplicateEmail;
        return null;
    }
    bool? tryExists = regTryExists(email);
    if (tryExists.HasValue && tryExists.Value && !userExists)
    {
        UserRepository.CreateUser(email, password);
        status = MembershipCreateStatus.Success;
        return GetUser(email);
    }
    return null;
}

也,因此我不需要GetUserNameByEmail, FindUsersByName方法:

public override string GetUserNameByEmail(string email)
{
    return email;
}  
public override MembershipUserCollection FindUsersByName(string usernameToMatch, int pageIndex, int pageSize, out int totalRecords)
{
    throw new NotImplementedException();
}

这里我不需要username, passwordQuestion, passwordAnswer, isApproved参数

而且,在我的系统中没有用户问题,所以我不需要像

这样的方法
public override bool ChangePasswordQuestionAndAnswer(string username, string password, string newPasswordQuestion, string newPasswordAnswer)
{
    return false;
}
public override string ResetPassword(string username, string answer)
{
    throw new NotImplementedException();
}

而这只是浪费和繁琐的会员制度的一部分。它不像我想要的那么可靠。

所以问题是使用MembershipProvider真的值得吗?请你带我过去好吗?会员制有什么优点使它真正有价值吗?

自定义会员提供程序是真正值得遵循的东西吗?

使用MembershipProvider本质上归结为任何开发人员(或开发经理)必须做出的"构建或购买"决定:从头构建,还是购买现成的(或者在这种情况下,使用预先存在的工具)。

考虑到这一点……诚然,MembershipProvider并不完美——它有点笨拙,而且可能有太多(或太少)您需要的东西——但对于大多数实现来说,它已经完成了85%的工作。正如其他人所暗示的那样,从头开始构建自己的身份验证系统不值得花费时间和精力。这是一个解决的问题;将您的开发精力用于解决更紧急和相关的业务问题,而不是重新发明轮子!

记住这个公理:除非你能从从头开始开发某个东西中获得直接的竞争优势,否则你(通常)最好使用现有的工具来完成这项工作(购买,而不是构建)。

ASP的一些优点。. NET成员提供程序API:

    你没必要重新发明轮子。项目的新成员将熟悉一个知名的API。
  • 已经有可用的实现(SQL Server, Active Directory主要),您可以重用或开始。
  • 它在视觉上与ASP集成。. NET(登录控件等)
  • 您可以使用内置的ASP。. NET管理工具创建用户&角色(这实际上是检查提供程序工作正常的好方法,因为它应该与工具一起工作)
  • 它可以与。net(不仅仅是ASP.NET) Identity/Principal类集成,并且可以用来支持PermissionAttribute系统(与关联的角色提供者)。虽然它技术上存在于System.Web.dll中,但实际上您可以在非web系统中使用它。
  • 最后一件很有趣的事:你也可以使用ASP。. NET成员资格提供程序在WCF服务

MembershipProvider确实很有用。完整的ASP。网络安全基础设施是围绕它建立的。许多控件可以直接与此基础结构交互,例如Login、LoginStatus。所以它确实有它的优势。
但由于其臃肿的界面,它也有相当大的问题。它打破了接口隔离原则,因此使用起来有点麻烦。我相信利大于弊。因此,只要有简单的解决方法,使用它就没有危害。
构建您自己的安全基础设施也不是一项简单的任务。

我最初使用自定义提供程序,但现在完全切换了。

我只保留了一个原则,比如什么时候锁定用户,如何散列密码,等等

在我需要不同数据库的多租户支持之前,我对自定义提供商很满意。最后,我尝试对使用会员提供程序的WCF服务进行单元测试。现在我有了会员资格,生活很好。我的数据结构几乎和原来一样,但在。net中我使用了我的代码

听起来默认的MembershipProvider可以做您需要它做的一切。
因此,我绝对建议创建一个UserBusiness类来包装MembershipProvider,并且只暴露您使用的特性。

这样可以很容易地使用MembershipProvider的强大功能,但也简化了您需要的界面。