asp.net - 如何在 EF DbContext 和 AspNet Membership 之间共享连接以避免事务升级到 DTC

Question

我有一个 ASP.NET MVC3 应用程序，它使用 EF 4.1 DbContext，数据库优先数据层。 EDMX 方法工作正常，因为我倾向于在使应用程序适应它们之前对我的数据模型进行更改。该应用程序可以与包含元数据引用的特殊 EF 连接字符串一起正常工作。

然而，美中不足的是一只苍蝇。该应用程序还使用需要标准连接字符串的 ASP.NET 成员资格和角色。我有几个用例涉及成员资格表和其他(EF 托管)表。由于两者使用单独的连接字符串，因此涉及两者的事务都需要 DTS 来处理它们。如果我能帮上忙，我不想走那条路，我宁愿应用程序的所有部分都使用相同的连接。

然而，让 EF 使用普通连接字符串运行却让我望而却步。谁能告诉我它是怎么做的，好吗？

Answer 1

您在这里有多种选择。 (我知道这很长，但请尝试阅读整篇文章)。如果您可以给出需要此类交易的实际场景，那将会有所帮助。

首先，您正在做一个错误的假设，即如果 EF 和 Membership 具有相同的连接字符串，它将使用公共(public)连接。有时这可能是正确的，但不能保证。连接池尝试对给定的字符串使用相同的连接，但如果连接已在使用中，它将创建第二个连接(或重用池中已有的第二个连接)。因此，这种推理方式会在某些时候给您带来麻烦。

Membership 旨在解决的问题之一是拥有一个可插入的提供程序接口(interface)，因此您可以更换成员资格提供程序并移动到另一个(例如从 Sql 到 ActiveDirectory)，而无需修改您的应用程序(或修改它很多)。

更紧密地集成这些功能意味着放弃这些好处。也许这是可以接受的，但您应该意识到沿着这些路径走基本上将您的数据模型与特定的 Membership 提供程序模式紧密耦合。几年前，这似乎不是问题，因为成员(member)系统多年来一直没有改变……但最近，MS 和其他公司一直在引入新的成员(member)系统，例如 SimpleMembership 和 Universal Providers，它们具有不同的架构.

那么，如果我们要删除 Membership 的主要功能之一，为什么还要继续使用它呢？那么，成员(member)资格仍然有一些好处。主要是它提供了用户管理库的开箱即用的完整实现，包括安全密码加密/散列和问答身份验证等功能。这不是小事，因为从头开始创建一个安全、无漏洞的成员(member)系统并非易事(尽管乍一看似乎如此)。

因此，一种选择是基于现有的 MembershipProvider(如 SqlMembershipProvider。Microsoft 为这些提供源)实现您自己的 MembershipProvider。然后，您可以简单地覆盖架构以匹配您想要的任何内容，但保留所有其他功能，例如密码加密等等。只需将它们放入您自己的架构中即可。这使它们更适合您的数据模型。

但是，即使您选择使用标准成员(member)服务提供商，您也可以做一些事情。

首先，您可以简单地将成员资格表映射到 Entity Framework 模型中。只需将它们拖放到您的设计器上，或将它们添加到 Code First 中。但是，如果您这样做，您应该只将它们用作只读，并且您不应该在成员资格表和您的表之间创建外键关系。相反，只需在您的 EF 查询中进行手动连接(这样工作量更大，但更安全)并将它们视为独立表。

好的，那么在需要更新或删除成员资格表中的数据作为查询的一部分的情况下呢？坦率地说，如果您使用标准成员资格表，我认为几乎没有任何理由必须发生这种情况。

Membership 表非常简单，其中包含非常少的实际数据，作为应用程序中任何语句的一部分，您应该需要这些数据。除非您使用的是 Profile 提供程序，我从不这样做。如果您需要映射成员资格表，我建议您创建自己的数据表而不是使用 ProfileProvider。

我看到您可能希望在何处登记交易的唯一原因是在创建新用户时。不过，既然这是一次性事件，那么 DT 可能就不是那么可怕的事情了。但是，您可能并不总是可以使用 DTC……所以在这些情况下，您能做的最好的事情就是使用 try-catch 块来处理异常。

另一种方法是完全放弃 Membership 并创建您自己的 IPrincipal 和 IIdentity 实现并简单地编写您自己的用户管理(我仍然会使用 SqlManagementProvider 源作为此的基础，但是，因为它是一个很好的实现)。

然后，由于用户管理不是单独子系统的一部分，您可以安全地使用它进行更新和删除，而不必担心其他子系统可能在做什么。

TL; 博士

如果你不能接受 DT，那么要么改变你的工作流程，改变你的代码以使用 try-catch-finally 语句(尽管这不能保证在应用程序代码突然死亡的情况下回滚，比如停电)，或使用自定义 IPrincipal 和 IIdentity 实现。