使用Linq-to-SQL，IOC和Repository模式预取数据

Question

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

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

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

2）我已经看到另一种可能性基于加载 数据及其子项在方法中，然后只返回数据（因此子项已经加载）{ {3}}

尽管如此，在我的架构中，它无法发挥作用：

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

是的，这个架构很安静很复杂，但是因为我可以使用乐高这样的代码，所以非常酷！）

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

Answer 1

我不知道其他可能性，看起来你已经将LinqToSql推到极限（但我可能错了）。

我认为你现在最好的选择是：

1. 在您的应用程序中添加一些“非泛型”方法来处理 您希望/需要急切加载的特定场景，而不是 为这些方法使用“普通”，“通用”基础设施。
2. 使用对eager和延迟加载有更复杂支持的ORM。

Answer 2

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

• 我的域模型和服务层向上不一定要依赖于LinqToSql提供程序（如果我愿意，我可以用接口替换我的DAL）
• 我的服务方法可以并且确实返回带有多个“锚点”的完整对象图，用于延迟加载使用抽象掉特定延迟加载实现的类 - 所以我可以使用特定于LinqToSql的不同执行或其他东西（例如，anon delegates）再次，请参阅this answer）
• 我可以在整个应用程序中维护IQueryable结果（如果我愿意，甚至可以在UI中），从而允许无限的LINQ查询链接，而不必担心性能。

Answer 3

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

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

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