我有一个3层ASP.NET MVC 3项目，它有一个数据层，服务层，然后是一个表示层，它调用服务层来获取数据。我实际上在动作解决方案中使用了doFactory模式。
我想实现自定义成员资格，角色，个人资料提供程序，但我不确定在哪里放置它。我想把它放在服务层，然后让提供者调用DAO对象来获取信息。
还有其他想法吗？
答案 0 :(得分：2)
你的想法很好。虽然UI层与客户端交互并获取其密码，但您的服务层应 process 尝试进入系统。
您的操作方法会将信息传递给负责授权的服务对象。
您的服务层不知道它是否在网络应用程序中。
数据层只是存储信息的地方，而不是存储信息的位置。
您可以选择在会话中将用户的ID保留在UI层中。登录时，服务层将采用用户名/密码/其他并返回UserID。或者，您的操作方法每次都可以将会话密钥传递到服务层，以获取用户信息。
编辑由于评论：我在我当前的项目中做了这个（几百万美元的范围）。我在操作方法中有安全决定。 （当然，用于实现此简单的工具是来自服务层的对象。）例如，如果当前用户没有此角色或该角色，则将其重定向到拒绝页面，否则，执行此操作。 MyServiceLayerObject.DoThing()内部没有任何安全措施。
这是我的应用程序和许多其他人最简单的方法。 （“最简单”意味着它将被搞砸了。当涉及到安全性时，简单就是好！）由于Action方法是功能的网关，因此在服务层中具有安全性只会导致额外的工作并且实际上< em>模糊发生了什么安全问题。现在，这是我的应用，其中通常会有一个地方发生每个操作。
您的应用可能会有所不同。更多不同的操作方法和（特别是）不同的组件正在使用您的服务层功能，您希望使用授权方案锁定服务层功能的次数越多。许多人认为安全应该始终在服务层中，并且UI层中的任何其他安全操作都将是奖励冗余。我不同意。
答案 1 :(得分：1)
以下是我在寻找同样事物时发现的三层世界的会员提供商的现有实施......
http://elysianonline.com/programming/wcf-wrapper-for-asp-net-membership/
在这里......
http://elysianonline.com/programming/using-the-wcf-membership-provider/