如何避免使用会员提供商？
我们目前正在为瘦客户端簿记应用程序构建架构。 它应遵循两个主要要求：
- 应用程序应具有模块设计。 每个模块都可以拥有（并且实际上拥有）自己的角色系统。
- 以后的应用程序应适合在不同的机器上使用不同的数据库运行。
我们认为Asp.NET MVC 3是适合这项任务的平台。 为了管理应用程序数据，我们选择了最新版本的Entity Framework – 它的批量数据提供程序和Code Firstfunction可以为我们节省大量时间。
我们纠结的部分是用户/角色管理系统。 我们应该有一些全局管理部分用于添加用户并授予他们模块访问权限（只有全局管理员可以将用户添加到系统，不支持“街头人”注册）并且每个模块都有自己的管理部分和自己的管理员和角色。 我们已经有了数据模型以适当的方式存储我们需要的所有内容，但不知道如何从应用程序正确访问这些数据。
目前，我们看到两种可能的方法来解决此问题：
- 根据我们的DAL编写自定义成员资格和角色提供程序。 我们团队中没有人这样做过，所以我们不确定这种方式是否值得。 会员提供商不能提供与应用程序需求一样多的灵活性，因此需要一些紧急情况。
- 挖掘一些过时的书籍，了解在创建成员资格提供者之前如何组织网站管理系统。
这两种方式都不优雅，对我们来说并不明显，而且选择哪种方式也不是一个简单的问题。 我们也相信它可以是其他解决方案（因为架构可能会受到影响）。 因此，我们很高兴看到任何与此问题相关的建议。
我个人建议首先使用标准成员资格提供程序来创建和validation用户，然后一旦您确认用户不仅仅是某个“来自街头的人”，请使用您自己的自定义架构来validation经过身份validation的用户可以访问他们尝试访问的控制器和操作。
内置成员资格提供程序在用户身份validation，密码存储等方面处理了许多细微差别。 它使用最佳实践来避免暴力攻击，彩虹表攻击等。它是经过validation的。
但听起来您的每个模块的权限结构可能适合或不适合ASP.NET角色提供程序的模式。 如果他们这样做，这一切都很好，并且实现自定义角色提供程序是个好主意。 但是，如果您的需求是“开箱即用”，那么您最好只需在最适合您的位置手动检查权限（控制器，操作，请求filter等）。
我鼓励您使用自定义会员提供商。 为什么？ 导致它的标准方式，将为您节省大量的工作。 它并不像我看到的那么难，而且有很多像这样的资源。
- 根据我们的DAL编写自定义成员资格和角色提供程序。 我们团队中没有人这样做过，所以我们不确定这种方式是否值得。 会员提供商不能提供与应用程序需求一样多的灵活性，因此需要一些紧急情况。
如果默认设置不提供您需要的function，那么这是非常值得的。 如果数据库中已有复杂的用户系统，则自定义成员资格提供程序可能是个好主意。
它将为您的团队增添宝贵的经验，您应该能够在下一个项目中重用大部分代码。 正如@Randolf所说，有很多很好的资源可以建立一个客户会员提供者，当我说它并不是那么困难时，我会说一些经验。 一切都在那里，你只需要实现一些方法。
好吧，最后我们决定从头开始编写，它似乎更容易
- 添加自己的IPrincipal实现。 IsInRole（）方法的附加字段和完全不同的逻辑，以避免编写自己的属性。
- 将Global.ajax事件中的IPrincipal分配给User。
这根本不难。 现在我们拥有了我们想要的所有灵活性。 没有提供商参与。