使用 LINQ to C# 的最佳模式是什么 [关闭]答案

【问题标题】：What is the best pattern to use LINQ to C# [closed]使用 LINQ to C# 的最佳模式是什么 [关闭]
【发布时间】：2014-02-27 19:26:29
【问题描述】：

公共类 CommonService { 私有只读DataContext _context；公共公共存储库（） { _context = new DataContext(); } 公共 CommonRepository（DataContext 上下文） { _context = 上下文； } 公共列表 GetAll() { var query = from m in _context.MyModel 选择米；返回 m.ToList(); } }

或

公共类 CommonService { 公共列表 GetAll() { 使用（数据上下文上下文 = 新数据上下文（）） { var query = from m in context.MyModel 选择米；返回 m.ToList(); } } }

或者你有更多的模式，请给我建议。

【问题讨论】：

请注意，您的问题是：“我是否应该在碰巧使用 LINQ 的代码中使用/允许 依赖注入？” - 回答：是的...请说明您正在寻找什么样的建议。
@AlexeiLevenkov，确实如此，但正如您所指出的，如果不知道 CommonService 的生命周期行为，就很难评估。如果它是单例，永久数据上下文将是一个非常糟糕的主意。
没有best 方式...
他不值得投反对票。
@walther，您是否将此作为一般规则？或者只是在这种特定情况下？无论哪种方式，我相信如果有足够的参数，这里实际上会有一个“最佳”答案。

标签： c# linq datacontext

【解决方案1】：

这里有一个主要区别：第一个代码示例在服务的生命周期内保留一个 DataContext，而第二个示例为每个操作创建一个新的。第二个示例通常是正确的，因为使用更改跟踪，DataContext 可能会变得很大，如果其他调用 SubmitChanges()，您可能会意外提交您不打算提交的内容。

见Multiple/single instance of Linq to SQL DataContext

【讨论】：

一个模棱两可的问题的好答案。需要强调的是，长时间保留数据上下文几乎总是一个非常糟糕的主意。

【解决方案2】：

您可以同时使用这两种模式，但请始终确保上下文的生命周期较短。第一个选项允许您在 CommonService 中创建需要上下文的方法，但不必在每个方法中都创建一个。因此它可以防止重复代码。此外，它还允许 IoC 容器通过构造函数注入将上下文注入CommonService。

如果你选择第一个选项（我倾向于这样做），你可以考虑让CommonService 实现IDisposable，给它一个Dispose 方法来处理上下文。这也将鼓励您在 using 构造中使用 CommonService，从而限制其生命周期。

【讨论】：