【发布时间】：2014-07-12 01:59:59
【问题描述】：
我最近开始学习 ASP.NET，经过阅读，我决定尝试使用身份验证用户。我已经阅读了几篇关于自定义模型的文章，例如实现我自己的 UserStore 类以提供持久性（如果我想将身份验证信息存储在其他地方）。
但我喜欢经典的 SQL DB，我不喜欢实体框架代码优先方法（我不知道 EF，我使用 LINQ to SQL 作为我的 ORM）。我被它困住了吗？ UserManager 需要一个 IdentityDBContext，它是一个 EF 上下文类，不是吗？
我应该这样做：
1) 为我的应用程序逻辑的其余部分创建一个新数据库，为 ORM 使用 LINQ - 似乎可行，但不是解决此问题的正确方法
2) 将其余记录放入同一个数据库，为它们创建 LINQcontext，并有效地拥有 2 个上下文，每个上下文都有一半的类 - 这似乎有点疯狂
3)别再偷懒了，学习 EF，添加额外的 DBset 属性到 ApplicationDBContext 并为所有内容提供 1 个上下文。但是，例如，如果我已经有一个填充了来自任何用户的数据库，并且需要为此开发应用程序怎么办？这似乎是一种数据库优先的方法，然后呢？
我该怎么办？还是有其他选择？
我正在使用网络表单（似乎更容易进入），在 VS2013 中开发。
提前致谢！
【问题讨论】：
-
选择第三个选项。从一开始你可能会感到不舒服，但后来你会喜欢它。另一件事，如果您对用户凭证内容感兴趣，请阅读此内容。 msdn.microsoft.com/en-us/library/vstudio/…logcorner.wordpress.com/2013/08/29/…
-
您不喜欢 EF 的哪些方面？有许多关于使用它的教程和信息。此外，您不必使用 Code First 方法 - 您可以将实例指向您的数据库并让 EF 生成您的类对象
-
谢谢大家的回复。正如我所说，我不想使用 EF，因为我不熟悉它，并且想把注意力集中在学习 ASP.NET 上，而不是另一个 ORM。那么我将如何改变身份的代码优先方法呢？我知道我生成的 User 类必须实现 IUser 接口。然后呢？
-
为什么要从 Web 窗体开始学习 ASP.NET？为什么不是MVC？实体框架，对于大多数实际目的，应该取代 LINQ-to-SQL，并且在如何实现构造查询方面更加优化。
-
WebForms 似乎更...熟悉。我已经习惯了桌面应用程序中的 WinForms（我知道我知道，很古老）并且 WinForms -> MVC 比 WinForms->Webforms 迈出了更大的一步（至少对我来说它看起来是那样的）。
标签： c# asp.net entity-framework webforms