3

使用 Linq-to-SQL 我想预取一些数据。

1）常见的解决方案是处理DataLoadOptions，但在我的架构中它不起作用，因为：

  • 必须在第一个查询之前设置选项
  • 我正在使用 IOC，所以我不直接实例化 DataContext（我无法在实例化时执行代码）
  • 我的 DataContext 在 Web 请求期间是持久的

2）我看到了另一种可能性，基于在方法中加载数据及其子项，然后只返回数据（所以子项已经加载）在这里看一个例子

尽管如此，在我的架构中，它不能不起作用：

  • 我的查询被级联出我的存储库，并且可以被许多将添加子句的服务使用
  • 我使用接口，linq-to-sql 对象的具体实例不会离开存储库（是的，您可以使用接口和添加子句）
  • 我的存储库是通用的

是的，这个架构很复杂，但是很酷，因为我可以玩乐高之类的代码；）

我的问题是：预取数据的其他可能性是什么？

4

3 回答 3

1

我不知道其他可能性，似乎您已经将 LinqToSql 推到了极限（但是我可能错了）。

我认为此时您的最佳选择是：

  1. 向您的应用程序添加一些“非通用”方法来处理您想要/需要急切加载的特定场景，并且不要为这些方法使用您的“正常”、“通用”基础设施。
  2. 使用对预先加载和延迟加载具有更复杂支持的 ORM。
于 2009-10-24T11:41:35.900 回答
1

在我的应用程序中，我可能会使用您的潜在解决方案#2 的变体。这有点难以解释，但很简单：我在我的模型中使用自定义延迟类链接和延迟延迟加载，以便抽象出我利用的特定于 LinqToSql 的差异执行IQueryable。好处：

  • 我的域模型和服务层向上不一定必须依赖于 LinqToSql 提供程序（如果我愿意，我可以用接口交换我的 DAL）
  • 我的服务方法可以并且确实返回具有多个“锚点”的完整对象图，以便使用抽象出特定延迟加载实现的类进行延迟加载 - 所以我可以使用 LinqToSql 特定的差异执行或其他东西（例如匿名委托。再次，参考这个答案）
  • 我可以在整个应用程序中维护IQueryable结果（如果我愿意，甚至可以维护到 UI），从而允许无限的 LINQ 查询链接，而不必担心性能。
于 2009-11-08T07:02:10.637 回答
0

我找到了解决方案。我的答案是“依赖注入”。

它通常与 IOC 一起提供，这意味着您可以让您的 IOC 容器在实例化时管理类的注入。

我只需要在实例化 DC 时注入一个CustomDCParameter类。该类将包含规则，构造函数将应用所有规则。

于 2009-10-26T10:12:10.683 回答