您在这里有几个选择。(我知道这很长,但请尝试阅读全文)。如果您可以提供需要此类事务的实际场景,那将有所帮助。
首先,您的假设是错误的,即如果 EF 和 Membership 具有相同的连接字符串,它将使用公共连接。有时这可能是真的,但不能保证。连接池尝试对给定字符串使用相同的连接,但如果连接已在使用中,它将创建第二个连接(或重用池中已有的第二个连接)。因此,这种推理方式会在某些时候给您带来麻烦。
Membership 旨在解决的问题之一是拥有一个可插入的提供程序接口,因此您可以更换成员资格提供程序并移动到不同的提供程序(例如从 Sql 到 ActiveDirectory),而无需修改您的应用程序(或对其进行大量修改)。
更紧密地集成这些功能意味着放弃这些好处。也许这是可以接受的,但您应该意识到,沿着这些路径走本质上将您的数据模型与特定的 Membership 提供程序模式紧密耦合。几年前,这似乎不是问题,因为会员系统多年来没有改变……但最近,MS 和其他人一直在引入新的会员系统,例如具有不同模式的 SimpleMembership 和 Universal Providers .
那么,如果我们要删除 Membership 的主要功能之一,为什么还要继续使用它呢?好吧,会员资格仍然有一些好处。主要是它提供了一个开箱即用的用户管理库的完整实现,包括安全密码加密/散列和问答认证等功能。这不是什么可以打喷嚏的事情,因为从头开始构建一个安全、无错误的会员系统并非易事(尽管起初看起来如此)。
因此,一种选择是基于现有的 MembershipProvider 实现您自己的 MembershipProvider(如 SqlMembershipProvider。Microsoft 为这些提供了源代码)。然后,您可以简单地覆盖架构以匹配您想要的任何内容,但保留所有其他功能,例如密码加密等等。只需将它们放入您自己的架构中即可。这使它们更适合您的数据模型。
但是,即使您选择使用标准会员提供程序,您也可以做一些事情。
首先,您可以简单地将成员表映射到您的实体框架模型中。只需将它们拖放到您的设计器上,或在 Code First 中添加它们。但是,如果您这样做,您应该只将它们用作只读,并且您不应该在成员资格表和您的表之间创建外键关系。相反,只需在您的 EF 查询中进行手动连接(这样工作量更大,但更安全)并将它们视为独立表。
好的,那么作为查询的一部分,您需要从成员表中更新或删除数据的情况呢?坦率地说,如果您使用的是标准成员资格表,我认为几乎没有理由会发生这种情况。
Membership 表非常简单,其中几乎没有实际数据,您应该在应用程序中的任何语句中都需要这些数据。除非您使用的是个人资料提供程序,否则我从不这样做。如果您需要映射成员表,我建议您创建自己的数据表,而不是使用 ProfileProvider。
我看到您可能想要在哪里登记交易的唯一原因是在创建新用户时。不过,既然这是一次性事件,那么DT可能就不是那么可怕的事情了。但是,您可能并不总是有可用的 DTC ......所以在这些情况下,您能做的最好的事情就是使用 try-catch 块来处理异常。
另一种方法是完全抛弃 Membership 并创建您自己的 IPrincipal 和 IIdentity 实现并简单地编写您自己的用户管理(但是,我仍然会使用 SqlManagementProvider 源作为此基础,因为它是一个很好的实现)。
然后,由于用户管理不是单独子系统的一部分,您可以安全地使用它进行更新和删除,而不必担心其他子系统可能在做什么。
TL;博士
如果您不能接受 DT,那么要么更改您的工作流程,更改您的代码以使用 try-catch-finally 语句(尽管这不能保证在应用程序代码突然死亡的情况下回滚,例如断电),或使用自定义 IPrincipal 和 IIdentity 实现。