ASP.NET 拆分成员资格并使用存储库模式

发布于 2024-08-21 18:46:24 字数 515 浏览 4 评论 0原文

我正在使用 asp.net mvc、DI、IoC、TDD 构建一个应用程序作为学习练习。

对于数据访问,我使用存储库模式。现在我正在研究成员资格以及它如何与存储库模式一起工作。我当前正在使用 Linq to Sql 存储库,但不想与 SQL Server 绑定以获得成员资格。

其次,我希望将会员资格分为许多服务:

  • AuthenticationService - 识别用户
  • AuthorizationService - 他们可以做什么
  • PersonalizationService - 配置文件

个性化服务将真正定义我的应用程序中的“客户”,每个客户都会有一个与 AuthenticationService 相关联的唯一 id/用户名 - 因此,允许我使用默认的 ASP.NET 会员提供程序、推出我自己的提供程序或使用 Open ID 之类的内容。

这是一个好方法吗?我不想重新发明轮子,而是希望应用程序的这些重要部分遵循与其余部分相同的模式。

谢谢 本

I am building an application using asp.net mvc, DI, IoC, TDD as a bit of a learning exercise.

For my data access I am using the repository pattern. Now I am looking at membership and how this can work with the repository pattern. I am currently using a Linq to Sql repository but don't want to be tied to SQL Server for membership.

Secondly, I am looking to split out membership into a number of services:

  • AuthenticationService - identify the user
  • AuthorizationService - what can they do
  • PersonalizationService - profile

The personalization service will be what really defines a "customer" in my application and each customer will have a unique id/username that ties back to the AuthenticationService - thus, allowing me to use the default ASP.NET Membership provider, roll my own or use something like Open ID.

Is this a good approach? I don't want to reinvent the wheel but would rather these important parts of my application follow the same patterns as the rest.

Thanks
Ben

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

尤怨 2024-08-28 18:46:24

老实说,实现我想要的目标是一个非常简单的过程。我还没有实现 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 替换默认的 SqlMembershipProvider,那么我只需要更改 web.config。为了支持不同类型的身份验证(可能是表单身份验证和开放 ID),我可以为每个身份验证创建一个控制器操作,并在设置身份验证 cookie 之前调用适当的 IAuthenticationService.ValidateUser 实现。

认证过程用于识别“用户”。为了获得“客户”,我正在使用个性化服务。其界面也非常简单:

public interface IPersonalizationService {
    Customer GetCustomer(string username);
}

这会返回我的客户(包含地址、过去的订单 - 我们真正关心的东西)。如果传入的用户名不存在客户对象,则 GetCustomer 方法将创建一个客户对象。因此,如果使用标准表单身份验证,无论如何在注册期间都会创建客户。如果使用 OpenID 之类的东西,他们第一次登录时将创建一个客户对象并将其链接到他们的 OpenID 用户名(因此将经过身份验证的“用户”与“客户”分开。

此过程也适用于匿名结账因为我可以为“访客”客户创建一个内存客户对象,最后在他们进行购买时将其保存到数据库中。在这种情况下,我没有用户(因为他们没有进行身份验证),但我有。 我对这个实现非常满意

,我想我会推出自己的会员提供程序(因为它并不是那么困难),并且我想使用存储库模式进行数据访问。 <

我使用过的一些资源:

a href="http://noahblu.wordpress.com/2009/02/19/custom-membershipprovider-using-repository-dependency-injection-pattern-magic/" rel= “nofollow noreferrer”">http://noahblu.wordpress.com/2009/02/19/custom-membershipprovider-using-repository-dependency-injection-pattern-magic/

http://davidhayden.com/blog/dave/archive/2007/10/11/CreateCustomMembershipProviderASPNETWebsiteSecurity.aspx

http://pbdj.sys-con.com/node/837990/移动

http://mattwrock.com/post/2009/10/14/Implementing-custom-Membership-Provider-and-Role-Provider-for-Authinticating-ASPNET-MVC-Applications.aspx

To be honest, to achieve what I wanted was quite a simple process. I haven't implemented the AuthorizationService yet but this will follow a similar pattern.

My authentication service is quite simple:

public interface IAuthenticationService
{
    bool IsValidLogin(string username, string password);
}

There will be a CreateUser method but I haven't implemented this yet.

Creating an authentication service using the standard membership provider is a simple task:

public class AspNetAuthenticationService : IAuthenticationService
{
    public bool IsValidLogin(string username, string password)
    {
        return Membership.ValidateUser(username, password);
    }
}

If I want to swap out the default SqlMembershipProvider with my own then I just need to change web.config. In order to support different types of authentication (perhaps forms auth and open id) I can just create a controller action for each and call the appropriate IAuthenticationService.ValidateUser implementation before setting an auth cookie.

The authentication process if for identifying the "user". In order to get the "Customer" I am using a PersonalizationService. The interface for this is again quite simple:

public interface IPersonalizationService {
    Customer GetCustomer(string username);
}

This returns my customer (with addresses, past orders - the stuff we really care about). The GetCustomer method will create a customer object if one doesn't exist with the passed in username. So if using standard forms auth a customer will be created anyway during registration. If using something like OpenID, the first time they login a customer object will be created and linked to their OpenID username (hence the reason for separating what an authenticated "user" is from a "customer".

This process also works well for anonymous checkout since I can create an in memory customer object for "guest" customers, and finally persist this to the database if they make a purchase. In this case, I don't have a user (cause they didn't authenticate) but I do have a customer.

I am quite happy with this implementation. I think I will roll my own Membership Provider (since it's not really that difficult) and I would like to use the repository pattern for the data access. Interested to hear any opinions / suggestions on this approach.

Some resources I have used:

http://noahblu.wordpress.com/2009/02/19/custom-membershipprovider-using-repository-dependency-injection-pattern-magic/

http://davidhayden.com/blog/dave/archive/2007/10/11/CreateCustomMembershipProviderASPNETWebsiteSecurity.aspx

http://pbdj.sys-con.com/node/837990/mobile

http://mattwrock.com/post/2009/10/14/Implementing-custom-Membership-Provider-and-Role-Provider-for-Authinticating-ASPNET-MVC-Applications.aspx

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文