SimpleMembership - 有人让它对 n 层友好吗？

Question

我们被告知，“SimpleMembership”是asp.net 成员/角色管理的 future 。
MVC4“互联网应用程序”模板使用 SimpleMembership 实现账户管理。但是，它的实现方式将所有应用程序层合并为 1。

让我感到震惊的是，在他们为使用 MVC 正确分层应用程序所做的所有工作之后，我们得到了这种用于没有 DI、使用 WebMatrix DLL 和完全缺乏 SoC 的成员(member)资格的“前进之路”的伪劣实现。特别是 SimpleMembershipInitialization 的 ActionFilterAttribute - 它继承自 MVC 属性并直接调用 EF DBContext。

我意识到我很懒惰，但是有没有人使用 SimpleMembership 做了一个“正确的”模板，这意味着我可以在我的应用程序中有适当的分隔层，并且在我的 MVC 应用程序中没有 EF DBContext 引用？

Answer 1

SimpleMembership 的强大概念之一是您可以自定义用户配置文件以满足您的应用程序需求，如 discussed in this article .例如，您可能想要 add email confirmation to your registration process这将需要将用户的电子邮件地址存储在用户配置文件中。在以前的 ASP.NET 成员/角色管理中，这很难实现，并且添加的属性存储在 blob 中。呸!

那么这与您关于使 SimpleMembership n-tier 友好的问题有什么关系？虽然我同意模板生成的内容对 n 层不友好，但我还要指出，大多数真正复杂的 MVC 应用程序都需要自定义 SimpleMembership，因此无论如何都需要创建一个特定于应用程序要求的层或层。换句话说，为 SimpleMembership 创建一个可重用的层只会在最基本的 MVC 应用程序中有用。

就我个人而言，我得出的结论是，Internet 模板生成的关于 SimpleMembership 的内容几乎总是会被修改。作为first article I referenced指出定制的第一部分是摆脱 SimplemembershipInitialization 属性，这只是在开发人员不使用表单例份验证的情况下初始化 SimpleMembership 的一种懒惰方式。通常，您会希望将 SimpleMembership 使用的 DBContext 移动到应用程序其余部分的 DBContext 中。用户配置文件通常与应用程序域的其余部分紧密集成。

由于我们讨论的是 SoC 和 ASP.NET 安全性，我认为 ASP.NET 在这方面从来都不是很好。对于表单例份验证，您可以在 Controller 和/或将角色作为参数的操作上使用 Authorize 属性。这迫使应用程序开发人员在设计应用程序域时考虑安全设计。您必须预先确定应用程序将具有哪些角色，并且天堂禁止它们稍后更改，因为现在您必须检查所有这些属性并相应地更新它们。我已经开始使用自定义授权属性，该属性将资源名称和操作类型作为参数(例如:读、写、执行...)。然后我可以将角色映射到数据库中的资源/操作，以便它可以轻松更改，甚至允许管理员更改角色在应用程序中的实现方式。微软对 ClaimsPrincipalPermissionAttribute 采取了同样的方法。现在他们已经合并了WIF进入.NET 4.5。

2013 年 3 月 8 日更新

我在 CodePlex called SimpleSecurity 创建了一个开源项目将 SimpleMembership 与 MVC 应用程序分离。您可以read about it here .我仍然认为开发人员很可能想要修改 SimpleSecurity，但由于这是开源的，他们可以。我们将看看这是否可以发展成为可重用和更好的 SimpleMembership。