10

我正在创建(实际上是重新创建)一个在 MS-Access 数据库中具有现有用户和其他数据的应用程序。数据将被移动到 SQL Server,其中一部分涉及迁移用户。我想用 EF 做 ORM,我很确定我知道 SQL Server 中的数据模型是什么。我是 EF 新手,但不是 ASP.NET,我想利用 ASP.NET 中的成员资格功能。我正在考虑几种方法来做到这一点,并希望得到一些建议。到目前为止,我只对这个想法做了一点研究,也许它已经在其他地方得到了回答。所以,这里有一组相关的问题。

  1. EF 可以通过某些我不知道的类或命名空间直接与 ASP.NET 成员身份一起使用吗?

  2. 如果我将用户转换到会员系统,为了将他们的用户 ID 与其他表中的数据对齐,我是否应该在 aspnet_* 表的顶部创建另一组用户数据表(如 DotNetNuke)?

  3. 我想避免在处理用户标记数据时仅将内置成员资格函数用于用户身份验证并切换到 EF 上下文的情况。通过进入每一行的会员用户来撤回用户信息以绑定到 GridView 中的列似乎很笨拙,但也许这就是所需要的?为了数据检索的目的,我是否需要吸收它并复制 EF 中的成员资格类?

  4. 我正在考虑为会员资格实施某种 EF 提供程序,其想法是,也许提供程序可以位于整个 EF 数据模型中。这是疯话吗?(我以前从未编写过自己的提供程序)

随意告诉我我没有任何意义。

4

2 回答 2

5

为什么不反过来呢?您可以为 asp.net 实现您自己的 Membership 提供程序,它使用您想要/需要的模型。

如果您需要的功能与内置的 asp.net 成员实现不完全匹配,您可以滚动您自己的提供程序。如果您只使用几个特性,您将只需要实现几个方法(您不必为所有方法填写实现)。如果您需要的功能超出其支持的范围,则使用会员提供程序可能会妨碍您。

于 2009-03-06T21:36:23.710 回答
2
  1. 我们这样做,但我们不映射成员资格表。您不应假定使用 SQL 成员资格提供程序。
  2. 我们映射用户身份,而不是数据库 ID。微妙,但很重要。同样,请记住还有其他成员资格提供程序(例如,域身份验证)。
  3. 你能澄清这个问题吗?您不需要复制 EF 模型中的所有成员信息,但您需要一个已知身份的列表。
  4. 不,一点也不疯狂,但很困难,而且可能没有必要。
于 2009-03-06T20:49:51.997 回答