我有一个使用一个EF 4.1的DbContext，数据库的第一数据层的ASP.NET MVC3应用。 我倾向于适应应用程序之前进行修改，我的数据模型的EDMX方法工作得很好。 该应用程序工作正常，其中包括元数据引用的特殊EF连接字符串。
然而，有美中不足一个苍蝇。 该应用程序还使用ASP.NET成员资格和需要一个标准的连接字符串的作用。 我有一个同时涉及成员表和其他（EF管理）表的几个用例。 作为两个单独使用的连接字符串，交易同时涉及需要DTS来处理它们。 我不想去的路线，如果我能帮助它，我宁愿应用程序的所有部分简单地使用相同的连接。
获得EF与然而，一个普通的连接字符串躲避我跑。 谁能告诉我它是怎么做的吗？
在这里，您有几种选择。 （我知道这是很长，但请尝试读取整个事情）。 这将有助于如果你可以给你需要这样的交易的实际情况。
首先，你正在一个错误的假设，即如果两个EF和成员具有相同的连接字符串，它会使用一个共同的连接。 这可能是真的，有时，但不能保证。 连接池尝试使用一个给定的字符串相同的连接，但如果连接已经在使用它会创建第二个连接（或重用池中现有的第二已连接）。 所以，这样的推理将让你在在某些时候的麻烦。
其中的成员资格被设计来解决问题是有一个可插拔的提供者接口，这样你就可以换出会员提供商和移动到一个不同的（比如去从SQL到ActiveDirectory中），而无需修改应用程序（或有修改它了）。
更紧密地集成这些功能意味着，受益远投掷。 也许这是可以接受的，但你应该明白，沿着这条路径基本上是紧密结合数据模型的具体成员资格提供模式。 几年前，似乎并没有像它会为会员制的问题多年来一直没有改变......但最近，MS等人也不断推出新的会员系统等，其具有不同的模式SimpleMembership和环球供应商。
所以，如果我们将移除的成员的主要特征之一，为什么还要继续使用吗？ 嗯，还有从会员一些好处。 主要的一个是，它提供了一个开箱全面实施用户管理库，包括安全密码加密/散列和类似的问题和答案认证功能。 这可不是在打喷嚏，因为从头开始做一个安全的，无缺陷的会员制度是不平凡的（即使它会在第一次显得如此）。
因此，一种选择是基于现有的，以实现自己的MembershipProvider（如SqlMembershipProvider的。微软提供了源这些）。 然后，你可以简单地覆盖模式以匹配任何你想要的，但保留所有其他的功能，如密码加密，什么不是。 正好契合他们到自己的模式。 这使得它们适合你的数据模型好多了。
然而，即使您选择使用标准的会员供应商，然后有一些事情可以做。
首先，你可以简单地映射表成员到你的实体框架模型。 只需将它们拖放到你的设计师或代码第一次添加它们。 但是，如果你这样做，你应该只使用它们为只读，你不应该创建成员表和你的表之间的外键关系。 相反，只是做手工在EF查询连接（这是更多的工作，但更安全），并把它们作为单独的表。
好了，关于你需要作为查询的一部分，更新或删除成员表中的数据的情况呢？ 坦率地说，如果你正在使用标准的会员表我看到几乎没有理由这应该曾经有发生。
会员表是非常简单，在他们如果您需要在您的应用程序的任何声明的部分非常少的实际数据。 除非你使用的配置文件提供者，这是我永远不会做。 如果您需要映射成员表，我建议创建自己的数据表，而不是使用ProfileProvider。
我看到的唯一原因，你可能要征用事务，是创建一个新用户时。 然而，由于这是一个一次性的事件，那么DT可能不是这么可怕的事情。 然而，也有可能不总是DTC提供给你...所以在这种情况下，你能做的最好是使用try-catch块来处理异常。
另一种方法是完全抛掉成员和创建自己的IPrincipal和IIdentity的实现和简单的写你自己的用户管理（我仍然会用SqlManagementProvider源作为这个基础，但是，因为它是一个很好的实现）。
而且，由于用户管理不是一个独立的子系统的一部分，你可以放心地使用它的更新和而不用担心其他的子系统可能会做删除。
TL; DR
如果你不能接受DT，然后要么改变你的工作流程，改变你的代码与一个try-catch-finally语句工作（虽然这并不能保证回退的情况下，应用程序代码的突然离世，像停电）或使用自定义的IPrincipal和IIdentity的实施。
我在这里发现了一个答案： https://stackoverflow.com/a/3408209/1169670 。 添加“招募=假”在ASP.NET成员资格系统的连接字符串停止升级到DTC。
然而，这种方法只是阻止了会员制的交易争取。 这是足以让我的要求，但它可能不会在任何情况下。
你应该看看asp.net普遍提供商基于EF Codefirst它们。 会员架构暴露为POCO类和DBSet所以你应该能够在DBSet包括到一个共同的DbContext类http://nuget.org/packages/Microsoft.AspNet.providers.core
我不认为你可以得到EF使用“普通”连接字符串。
在一些应用中我有相同的正常和EF连接字符串并肩而坐
