我们被告知，“SimpleMembership”是asp.net 成员/角色管理的未来。MVC4“互联网应用程序”模板使用 SimpleMembership 实现账户管理。但是，它的实现方式将所有应用程序层合并为 1。
让我感到震惊的是，在他们为使用 MVC 正确分层应用程序所做的所有工作之后，我们得到了这种用于没有 DI、使用 WebMatrix DLL 和完全缺乏 SoC 的会员资格的“前进之路”的粗制滥造实现。特别是 SimpleMembershipInitialization 的 ActionFilterAttribute - 它继承自 MVC 属性并直接调用 EF DBContext。
我意识到我很懒惰，但是有没有人使用 SimpleMembership 做了一个“正确的”模板，这意味着我可以在我的应用程序中拥有适当的分隔层，并且在我的 MVC 应用程序中没有 EF DBContext 引用？
One of powerful concepts of SimpleMembership is that you can customize the user profile to fit your application needs, as discussed in this article. For example, you may want to add email confirmation to your registration process which will require storing the user's email address in the user profile. In the previous membership/role management for ASP.NET this was very ugly to implement and added properties were stored in a blob. Yuck!
So what does this have to do with your question on making SimpleMembership n-tier friendly? While I agree that what the template generates is not n-tier friendly I would also state that most real MVC applications of any complexity will require customizing SimpleMembership, and therefore will require making a tier or layer that is specific to the application requirements anyway. Stated another way, creating a reusable tier for SimpleMembership would only be useful in the most basic MVC apps.
Personally I have come to the conclusion that what is generated by the Internet template in regards to SimpleMembership will almost always be modified. As the first article I referenced points out the first part of customization is getting rid of the SimplemembershipInitialization attribute, which is just a lazy way of initializing SimpleMembership in the event the developer is not using forms authentication. And often you will want to move the DBContext used by SimpleMembership into the DBContext for the rest of your application. User profiles are often tightly integrated with the rest of the application domain.
And since we are on the subject of SoC and ASP.NET security, I would argue that ASP.NET was never very good at this. For forms authentication you use an Authorize attribute on your controllers and/or actions which takes a role as a parameter. This forces the application developer to think about security design while designing the application domain. You have to determine what roles the application will have up front, and heaven forbid they change later because now you have to go through all of those attributes and update them accordingly. I have started to use a custom authorize attribute that takes as parameters a resource name and an operation type (ex: read, write, execute...). Then I can map roles to resource/operations in a database so that it can change easily, or even allow an administrator to make changes to how roles are implemented in the application. Microsoft is taking the same approach with ClaimsPrincipalPermissionAttribute now that they have incorporated WIF into .NET 4.5.
Updated 3/8/2013
I have created an open source project on CodePlex called SimpleSecurity that decouples SimpleMembership from the MVC application. You can read about it here. I still think developers will most likely want to modify SimpleSecurity but since this is open source they can. We will see if this is something we can evolve to be a reusable and better SimpleMembership.
我认为您的问题更多地与 SoC 相关，而不是 n 层架构（正如@klatzib 所指出的，这更多的是关于层之间的物理分离）。
我认为成员资格提供程序中的逻辑不应归类为业务逻辑，因为它们不包含应用程序或客户端特定的代码。事实上，提供者模型的想法是它履行一个通用合同，而不管它使用的上下文。开发人员常犯的一个错误是在应用程序特定的业务逻辑中进行扩展MembershipProvider和栓接，而这些业务逻辑应该存在于更高层中。如果这就是您想通过替代设计实现的目标，那么这是错误的方法。提供程序是 .NET 框架的插件，应该完全从代码中抽象出来。它们当然不应该包含您的应用程序域，并且您应该很少需要扩展它们。
以另一种方式解决您的问题，是否SimpleMembershipProvider禁止在应用程序设计甚至 n 层架构中使用 SoC？不，它没有。MVC4 模板是为简单而构建的，但ActionFilter用于初始化提供程序的不是成员实现的一部分，您可以以任何您认为合适的方式自由初始化提供程序（我更喜欢从 DI 容器工厂方法进行此调用）。事实上SimpleMembershipProvider，因为根本不直接依赖 EF，所以可以在您的 Web 应用程序中删除对 EF DbContext 的引用。
接受的答案不正确，即不是 N-Tier。成员数据访问和业务逻辑发生在同一层。仅仅因为代码在不同的程序集中并不意味着它不在同一层。
如果没有到数据访问层的某种传输机制，这不是 N 层。
解决方案是继承和覆盖 WebMatrix SimpleMembershipProvider 类，以便可以在单独的主机上执行其数据访问调用。
我建议使用 dotPeek 查看 SimpleMembershipProvider，以便您知道在覆盖中要做什么。
正是我想要的（几乎）。只是希望它没有绑定到实体框架，因为我希望让 Kevin 的 n 层解决方案与 Dapper ORM 一起工作:(