实体框架多结果集、Azure连接恢复和命令拦截

Question

我正在尝试将连接Resiliency添加到我的Repository类并进行测试，以便将我的WCF服务移到Azure。朱莉·勒曼( Julie Lerman )有一个很棒的帖子：

http://thedatafarm.com/data-access/testing-out-the-connection-resiliency-feature-into-ef6/#comment-61311

当我调用使用普通实体框架查询的存储库方法时，将触发Interceptor ReaderExecuting方法，并且我能够模拟连接问题。

var states = dbContext.Blogs.ToList();

但是，由于某些原因，当我的存储库方法之一使用从存储-proc返回的“多个结果集”正在执行时，不会调用Interceptor ReaderExecuting方法(请参阅下面的代码)。我期望在执行"ObjectContext.Translate“或"ToList”时调用ObjectContext.Translate方法，但它没有：

db.Database.Connection.Open();

var reader = cmd.ExecuteReader();

var blogs = ((IObjectContextAdapter)db).ObjectContext.Translate<Blog>(reader).ToList();

FYI，我跟随本文来处理“多个结果集”：

https://msdn.microsoft.com/en-us/data/jj691402.aspx

我试图通过实体框架6+执行策略来处理连接Resiliency。但是，如果它不能处理多个结果集，我的下一个选择将是使用Polly库进行瞬态异常处理。

你遇到过这种情况吗？

你有什么解决办法吗？

Answer 1

由于@tdykstra提到的EF限制，我更改了存储的-proc以返回XML输出，而不是“多个结果集”。我使用"SqlQuery“方法调用存储的-proc并获取输出XML，然后将该XML反序列化为对象。这样，Interceptor ReaderExecuting方法就被执行了，并且我能够测试连接的可靠性。希望EF团队在未来的版本中增加对“多个结果集”的更多支持。下面是示例代码：

var paramId = new SqlParameter
{
    ParameterName = "id",
    SqlDbType = SqlDbType.Xml,
    Direction = ParameterDirection.Input,
    Value = 1
};

var paramXmlResult = new SqlParameter
{
    ParameterName = "XmlResult",
    SqlDbType = SqlDbType.Xml,
    Direction = ParameterDirection.Output
};

db.Database.SqlQuery<XElement>(
    "EXEC [dbo].[GetDataAsXml] @id, @XmlResult OUT", 
    paramId, paramXmlResult).ToList();


XElement xmlResult = XElement.Parse(paramXmlResult.Value.ToString());

//FromXElement is an Extension method that deserializes XML into a Type (like MyData)
MyData data = xmlResult.FromXElement<MyData>();

Answer 2

您是否尝试过将来自自定义DbConfiguration实现的内置连接弹性连接连接，如下所示？

public class MyDbConfiguration : DbConfiguration
{
    public MyDbConfiguration()
        : base()
    {
        var strategy = System.Data.Entity.SqlServer.SqlAzureExecutionStrategy();
        SetExecutionStrategy("System.Data.EntityClient", strategy);
        SetExecutionStrategy("System.Data.SqlClient", strategy);
    }
}

我在火星上使用过这种方法，我对此没有异议。

Answer 3

在这个场景中，对ExecuteReader的调用超出了EF的范围--代码直接在ADO.NET命令对象上调用它。因为您为了执行命令而完全绕过EF，所以您忽略了所有EF (包括拦截器)。只需将已经检索到的结果转换为对象即可。