重写 Linq to SQL 中的实体缓存/更改跟踪行为

Question

我认为也许原来的问题太冗长了，有太多不必要的细节，所以这是我尝试简化的。

我正在寻找一种方法来执行任何以下的行动。我只需要做其中一项，而不是全部。如果有人知道其中之一的答案，请回复。那么，是否可以在 Linq to SQL 中执行以下任何操作：

• 通过 ExecuteQuery 或 ExecuteMethodCall 从 DataContext 中提取实体没有跟踪这些实体？

• 调用ExecuteQuery或ExecuteMethodCall并保证我始终收到从数据库检索到的结果的最新副本，即使这些实体已经被检索并且已经在身份缓存？

• 指示 Linq to SQL 不要对特定实体类型执行任何更改跟踪 - 但仍然允许其他类型的更改跟踪？

  指示

限制：

• Refresh 方法是不可能的；实体的数量相当大，这将成为性能灾难。

• 我不能简单地将 ObjectTrackingEnabled 设置为 false，因为 DataContext 不允许将其设置回 true执行查询后，我确实需要跟踪一些实体。

• 我也不能扔掉原来的 DataContext 并使用新的；我需要能够在事务中间执行此操作。

---

这开始成为一个严重的问题，我真的认为默认行为是考虑不周的。如果我执行临时查询或存储过程，我希望收到的结果与所述查询返回的结果完全相同。这才有意义；如果我想要旧的、过时的实体，为什么我要返回数据库来获取它们？

目前，我的解决方法是（a）专门为查询创建一个新的 DataContext 并覆盖事务隔离级别，或者（b）使返回类型为与以下内容相同的“DTO”：实体以各种方式但没有 [Table] 属性，并使用 AutoMapper 将其映射到原始实体。这两个看起来都是可怕的黑客行为。

非常感谢任何人对这个难题提出的任何建议。

Answer 1

我已经设法针对这个问题提出了一个可行的长期解决方法。它并不完全理想，但到目前为止使用起来相对轻松，并且远没有其他替代方案那么可怕。

由于这些查询无论如何都是纯 SQL - 它们都是用于内联 SQL 的 ExecuteQuery 或用于存储过程的 ExecuteMethodCall - 我决定直接使用“原始”ADO。 NET，例如当我不希望 DataContext 了解某些实体时。

当然，处理一堆 IDbCommand 实例和来自 IDataReader 的手动映射是很可怕的，所以今天早上我花了几个小时编写了一个库为我完成大部分繁重的工作，为 IDbCommand 公开一个“流畅”（我宽松地使用这个术语）包装器，这是一个使用 MetaModel 的自动 LinqDataReaderMapper 这样我就可以使用现有的实体而无需修改，以及一堆重载的扩展方法可以更快地编写更简单的查询。

在一天结束时，我正在写这样的东西：

var results = context.Connection
    .Command("SELECT Column1, Column2 FROM Table " +
             "WHERE FilterColumn1 = @Param1 AND FilterColumn2 = @Param2")
    .Parameters(
        p => p.Name("Param1").Value(someValue),
        p => p.Name("Param2").Value(someOtherValue))
    .ExecuteReader()
    .MapWith(context.Mapping).To<MyEntity>();

或者只是这样：

var results = context
    .ExecuteQueryRaw<MyEntity>(CommandType.StoredProcedure, "SomeProc",
        new { Param1 = someValue, Param2 = someOtherValue });

我不会发布它的整个代码 - 它很长，我认为它只是一个大的 tl;dr 此时 - 但主要思想是，它们都给我返回一个 IEnumerable，并且因为它们是直接从 IDataReader 复制的，它们本质上是独立的实体 - DataContext 没有直接了解它们，因此既不能拦截结果也不能在事后跟踪它们。

因此，问题部分解决了，尽管如果我能让 DataContext 自行运行，效果会更好。

Answer 2

如果您为 LINQ 查询的结果构造一个新对象，则不会跟踪它的更改。因此，您可以使用现有的 DataContext 来加载您知道不需要更新的值，如下所示（代码来自 此处）：

using (NorthwindDataContext context = new NorthwindDataContext())
{
  var a = from c in context.Categories
  select new Category
  {
    CategoryID = c.CategoryID,
    CategoryName = c.CategoryName,
    Description = c.Description
  };
}

我认为这基本上就是第二个示例中的内容在你的回答中，我只是想确认这是可行的，而且不是一个坏主意。

另外，我的理解是，在任何情况下都不应该使用单个庞大的 DataContext； DataContext 实际上是一个工作单元级别的集合，而不是整个世界。因此，对只读类型数据和可更新数据使用单独的 DataContext 是非常有意义的（我想，除非您无法提前预测哪个是哪个）。