identity - POCO 具有新的 ASP.NET Identity 和 MVC 5.0 + 基于声明的 Identity

Question

使用新版本的 VS 2013 RTM 和 asp.net mvc 5.0，我决定尝试一些东西...

不用说，发生了很多变化。例如，新的 ASP.NET Identity 取代了旧的 Membership 和(不太旧的)SimpleMembership API。

在我之前构建的所有应用程序中，我从未有机会使用 Membership 或 SimpleMembership。我总是最终创建自己的 Login() 方法，该方法会将提交的 ViewModel 转换为 POCO(使用自动映射器)，而 POCO 又会使用某种存储库来查找用户和密码。

作为返回，我将获得一个 User POCO，稍后将其转换(使用自动映射器)为较小的 UserSession POCO。较小的 UserSession 将放在 Session 中。

当然，我仍然会使用 FormsAuthentication 创建一个 Encrypted Ticket 并在用户想要注销时使用 FormsAuthentication.SignOut() .

但我从未充分利用Membership(或SimpleMembership)所提供的功能。

我从来没有让我的 POCO 实现某种接口(interface)，也不需要在我的 POCO 类库中添加对 Microsoft 库的引用。换句话说，我从来没有对任何东西产生过强烈的依赖。

我的问题如下:

通过我看到的示例，我不断看到新的 ASP.NET Identity 创建(通过代码优先)一些表和字段。例如，AspNetUsers 表将 Id 字段保存为字符串。当然，我确信有一种方法可以克服这个问题，并且最终会看到示例，但是为什么有人不想构建纯 POCO 类并完全控制事物是怎样创造的？

除非我感到困惑(很有可能)，否则任何人都可以解释为什么我想使用新的 ASP.NET Identity API(或更重要的是，使用新的 Microsoft.AspNet.Identity.EntityFramework) 创建我的表？

与 POCO 风格相比，想要使用它的优点和缺点是什么？

也许我应该在另一个问题中问这个问题，但我也试图了解如何在使用 POCO 而不是使用 ASP.NET Identity 生成的实体时受益于新的基于声明的身份。

请随时为我指出正确的方向以进行澄清。

Answer 1

您可以完全创建自己的 UserManager，除非您对它的工作原理有深入的了解，否则我不建议您这样做。您可以包装现有的 UserManager 并使您的应用程序依赖于接口(interface)或直接使用它并从中受益微软已经放入其中。如果您不喜欢 EF，您可以创建自己的存储来使用另一个数据库。新的 ASP.NET Identity 具有足够的可扩展性，我同意如果您想完全控制并自定义所有内容，这有点困难，但我建议您花时间了解其中的大部分内容，以便您可以选择何时使用或不使用。使用现有的 UserManager 就足够了。