SimpleMembership - 有人对n级友好吗？

Question

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

让我感到震惊的是，经过他们用MVC正确分层应用程序的所有工作后，我们得到了这种粗制的“成员资格的前进方式”实现，没有DI，使用WebMatrix DLL并完全没有SoC 。特别是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应用程序中有用。

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

由于我们讨论的是SoC和ASP.NET安全问题，我认为ASP.NET从来都不是很擅长这一点。对于表单身份验证，您可以在控制器上使用Authorize属性和/或将角色作为参数的操作。这迫使应用程序开发人员在设计应用程序域时考虑安全性设计。您必须确定应用程序将具有哪些角色，并且天堂禁止他们稍后更改，因为现在您必须完成所有这些属性并相应地更新它们。我已经开始使用自定义authorize属性，该属性将资源名称和操作类型作为参数（例如：read，write，execute ...）。然后，我可以将角色映射到数据库中的资源/操作，以便它可以轻松更改，甚至允许管理员更改角色在应用程序中的实现方式。由于他们已将ClaimsPrincipalPermissionAttribute合并到.NET 4.5中，因此Microsoft正采用与WIF相同的方法。

更新于2013年3月8日

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

Answer 2

接受的答案不正确，那不是N-Tier。成员资格数据访问和业务逻辑发生在同一层中。仅仅因为代码在不同的程序集中并不意味着它不在同一层中。

如果没有某种传输机制到数据访问层，这不是N层。

解决方案是继承并覆盖WebMatrix SimpleMembershipProvider类，以便可以在单独的主机上执行其数据访问调用。

我建议使用dotPeek查看SimpleMembershipProvider，以便您知道在覆盖中要做什么。

Answer 3

我认为你的问题更多地与SoC相关，而不是n层架构（更多的是关于层之间的物理分离，正如@klatzib所指出的那样）。

我认为成员资格提供者中的逻辑不应被归类为业务逻辑，因为它们不包含应用程序或客户端特定代码。实际上，提供者模型的概念是它履行通用契约，而不管其使用的上下文。开发人员犯的一个常见错误是扩展MembershipProvider并在应用程序特定的业务逻辑中进行操作，这应该存在于更高层中。如果这是您想要通过替代设计实现的目标，那么这是错误的方法。提供程序是.NET框架的插件，应该完全从代码中抽象出来。它们肯定不应该包含您的应用程序域，您很少需要扩展它们。

以另一种方式解决您的问题，SimpleMembershipProvider是否禁止应用程序设计中的SoC甚至是n层架构？不，它没有。 MVC4模板是为了简化而构建的，但用于初始化提供程序的ActionFilter不是成员资格实现的一部分，您可以以任何您认为合适的方式自由初始化提供程序（我更喜欢从DI容器工厂方法）。实际上SimpleMembershipProvider根本没有直接依赖于EF，所以是的，可以在你的网络应用中删除对EF DbContext的引用。

Answer 4

正是我所寻找的（差不多）。只是希望它不与实体框架联系在一起，因为我希望让Kevin的n层解决方案与Dapper ORM合作：（