LINQtoSQL，存储库模式和延迟加载答案

【问题标题】：LINQtoSQL , repository pattern and lazy loadLINQtoSQL，存储库模式和延迟加载
【发布时间】：2010-10-07 14:00:07
【问题描述】：

如何将 LINQtoSQL 与存储库模式一起使用？

我是 L2S 的新手，发现它的延迟加载是使用 repo 模式的真正障碍。

通常，我认为存储库模式是这样的：

var myCustomer = null;

using (var myRepo = new Repo()){
    myCustomer = myRepo.GetCustomerForCustomerId(123);
}

if(myCustomer.Orders.Any()){
 //do something
}

问题是，当 myCustomer.Orders 被询问时，L2S 不会尝试建立数据连接吗？这不会导致不可预测的数据库访问问题吗？

我的意思是，是的，我可以告诉我的 repo 验证 repo 内的订单，确信我们的完整测试覆盖验证开发人员永远不会调用我们没有明确加载的实体，但我宁愿摆脱惰性加载/对象数据上下文持久性。

所以我有 4 个选项

创建从 L2S 对象创建的域对象 - 大量工作和维护
创建破坏链接的 L2S 对象的派生版本 (http://www.codeproject.com/KB/linq/linq-to-sql-detach.aspx)
请改用 LLBLGenPro。
呼吁堆栈溢出阅读器的智慧

我现在选择 4。

如何确保我的对象在我的 repo 关闭后不会调用数据库？

是的，我确实阅读了所有关于 L2S 和 Repos 的堆栈问题，但没有一个人回答这个问题。

【问题讨论】：

我不知道答案，但我的印象是 L2S 或任何其他语言层往往比解决问题更可怕。有些人（包括我自己）对不知道幕后发生的事情感到恼火。
@vulkanino，只有没用过 L2S 的人才会这么说。你更喜欢什么，原始 SQL？
是的，数据库存储过程中的原始 sql 确实如此。程序源中没有sql代码。
我致力于使用一些 ORM 工具。过去使用过一个，我再也不会回到 sprocs 和 SQL 命令。我只是想弄清楚 L2S 是否以及如何给我在使用 LLBLGenPro 时所拥有的控制权。

标签： linq-to-sql repository repository-pattern

【解决方案1】：

有时对预先加载实体的子项很有用。您可以使用DataLoadOptions.LoadWith 来执行此操作，它会告诉您的 DataContext 在加载父实体时自动加载实体的子实体。

来自MSDN link above的片段：

Northwnd db = new Northwnd(@"c:\northwnd.mdf");
DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Customer>(c => c.Orders);
db.LoadOptions = dlo

您还可以使用DataLoadOptions.AssociateWith 进一步自定义自动加载的行为。

【讨论】：