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