我可以将实体框架与 ASP.NET 成员资格一起使用吗？
我正在创建（实际上是重新创建）一个应用程序，该应用程序在 MS-Access 数据库中包含现有用户和其他数据。 数据将移至 SQL Server，其中一部分涉及迁移用户。 我想使用 EF 来做 ORM，并且我非常确定我知道 SQL Server 中的数据模型是什么。 我是 EF 新手，但不是 ASP.NET，我想利用 ASP.NET 中的成员资格功能。 我正在考虑几种方法来做到这一点，并希望得到一些建议。 到目前为止，我只对这个想法做了一点研究，也许在其他地方已经得到了答案。 因此，这里有一系列相关问题。
EF 可以通过我不知道的某个类或命名空间直接与 ASP.NET 成员资格一起使用吗？
- 将用户转移到会员系统，为了将他们的用户 ID 与其他表中的数据对齐，我是否应该像 DotNetNuke 一样在 aspnet_* 表之上为用户数据创建另一组表？
我希望避免出现以下情况：仅使用内置成员资格函数进行用户身份验证，并在处理用户标记数据时切换到 EF 上下文。 通过进入每一行的会员用户来撤回用户信息以绑定到 GridView 中的列似乎很笨拙，但也许这就是所需要的？ 我是否需要吸收它并在 EF 中复制 Membership 类以用于数据检索目的？
我正在考虑是否为会员资格实现某种 EF 提供程序，这样该提供程序就可以位于整个 EF 数据模型中。 这是疯话吗？ （我以前从未编写过自己的提供程序）
请随意告诉我我没有任何意义。
I'm creating (really, re-creating) an app that has existing user and other data in MS-Access databases. The data will be moved to SQL Server, and part of that involves migrating users. I want to use EF to do ORM, and I am pretty sure I know what the data model will be in SQL Server. I am new to EF but not to ASP.NET, and I'd like to take advantage of the Membership features in ASP.NET. I am thinking about several ways to do this and would like some advice. I've done only a little research about this idea thus far, maybe it's been answered elsewhere. So, here goes a cluster of related questions.
Can EF work with directly with ASP.NET Membership through some class or namespace that I'm not aware of?
If I transition users to the Membership system, to align their userids with data in other tables should I create another set of tables for user data atop the aspnet_* tables a la DotNetNuke?
I want to avoid a situation where I use the built-in Membership functions for only user authentication and switch over to EF context when I'm working with user-tagged data. Seems clumsy to withdraw user info to bind to a column in a GridView by going into a Membership user for every row, but maybe that's what's needed? Do I need to suck it up and replicate the Membership classes in EF for data retrieval purposes?
I was thinking of maybe implementing some kind of EF provider for Membership, on the idea that maybe then the provider could sit inside the overall EF data model. Is this crazy talk? (I've never written my own provider before)
Feel free to tell me I am not making any sense.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么不反过来做呢？ 您可以为 asp.net 实现您自己的会员资格提供程序，该提供程序使用您想要/需要的模型。
如果您需要的功能与内置的 ASP.NET 成员资格实现不完全匹配，您可以推出自己的提供程序。 如果您只使用几个功能，则只需实现几个方法（您不必填充所有方法的实现）。 如果您需要的功能多于其支持的功能，那么使用会员资格提供商可能会妨碍您。
Why not do it the other way around? You can implement your own Membership provider for asp.net, that uses the model you want/need.
If the features you need aren't a complete match with the built-in asp.net membership implementation, you can just roll your own provider. If you will use just a couple features, you will have to implement just a couple methods (you don't have to fill implementation for all the methods). If you need more features than it supports, using the membership provider might get in your way.