我正在使用asp.net mvc，DI，IoC，TDD构建一个应用程序作为一个学习练习。
对于我的数据访问，我使用的是存储库模式。现在我正在研究成员资格以及如何使用存储库模式。我目前正在使用Linq to Sql存储库，但不希望绑定到SQL Server以获取成员身份。
其次，我希望将会员资格分成若干服务：
个性化服务将是我的应用程序中真正定义“客户”的内容，每个客户将拥有一个与AuthenticationService绑定的唯一ID /用户名 - 因此，允许我使用默认的ASP.NET成员资格提供程序，roll我自己或使用像Open ID这样的东西。
这是一个好方法吗？我不想重新发明轮子，但我希望我的应用程序的这些重要部分遵循与其余部分相同的模式。
由于 本
答案 0 :(得分：1)
看一下RIA Authentication, Roles, and Profiles service ...无需重新发明轮子。
答案 1 :(得分：0)
说实话，实现我想要的是一个非常简单的过程。我还没有实现AuthorizationService，但这将采用类似的模式。
我的身份验证服务非常简单：
public interface IAuthenticationService
{
bool IsValidLogin(string username, string password);
}
会有一个CreateUser方法，但我还没有实现它。
使用标准成员资格提供程序创建身份验证服务是一项简单的任务：
public class AspNetAuthenticationService : IAuthenticationService
{
public bool IsValidLogin(string username, string password)
{
return Membership.ValidateUser(username, password);
}
}
如果我想用自己的默认SqlMembershipProvider换出，那么我只需要更改web.config。为了支持不同类型的身份验证（可能形成auth和open id），我可以为每个身份验证创建一个控制器操作，并在设置auth cookie之前调用相应的IAuthenticationService.ValidateUser实现。
用于识别“用户”的验证过程。为了获得“客户”，我使用的是PersonalizationService。这个界面非常简单：
public interface IPersonalizationService {
Customer GetCustomer(string username);
}
这会返回我的客户（包括地址，过去的订单 - 我们真正关心的东西）。如果传入的用户名不存在，则GetCustomer方法将创建一个客户对象。因此，如果使用标准表格auth，则在注册期间无论如何都将创建客户。如果使用类似OpenID的东西，他们第一次登录客户对象将被创建并链接到他们的OpenID用户名（因此将经过身份验证的“用户”与“客户”分开的原因。
此过程也适用于匿名结账，因为我可以为“访客”客户创建内存客户对象，如果他们进行购买，最终会将其保留到数据库中。在这种情况下，我没有用户（因为他们没有进行身份验证），但我确实有一个客户。
我很满意这个实现。我想我会推出自己的会员提供商（因为它并不是那么困难），我想使用存储库模式进行数据访问。有兴趣听取有关此方法的任何意见/建议。
我使用过的一些资源：