哪个层应该创建 DataContext？答案

【问题标题】：Which layer should create DataContext?哪个层应该创建 DataContext？
【发布时间】：2011-01-30 06:10:09
【问题描述】：

我在决定系统中的哪个层应该创建 DataContext 时遇到问题。我看过一本书，说如果不为所有的数据传递相同的DataContext对象数据库更新时，它有时会从 DataContext 中抛出异常。这就是为什么我最初在业务层创建 DataContext 的新实例，并将其传递给数据访问层。以便所有更新都使用相同的数据上下文。但这会导致一个设计问题，如果我将来想将我的 DAL 更改为 Non-LinqToSQL，我还需要在业务层重新编写代码。请给我一些建议。谢谢。

示例代码

'Business Layer
Public Sub SaveData(name As String)
Using ts AS New TransactionScope()
Using db As New MyDataContext()
    DAL.Insert(db,name)   
    DAL.Insert(db,name)
End Using
ts.Complete()
End Using
End Sub

'Data Access Layer
Public Sub Insert(db as MyDataContext,name As string)
    db.TableAInsert(name)
End Sub

【问题讨论】：

标签： linq-to-sql architecture datacontext

【解决方案1】：

作为与 LINQ to SQL 紧密耦合的 DataContext，您绝对应该在 DAL 中创建它。

看看我提供给这个somewhat related SO question 的答案。它提出了相同的问题，即 DataContext（Entity Framework 中的 ObjectContext）是否应该在多个数据库操作中保持活动状态，或者是否应该临时创建和处置。

您所指的问题与model objects retrieved through a DataContext can only be updated using the same DataContext instance有关。现在，如果原始 DataContext 已被释放，任何将更新的模型对象附加到新 DataContext 实例的尝试都将失败。

但这不一定是问题，具体取决于应用程序的架构。
例如，通过 LINQ to SQL 检索和操作的模型对象在客户端之间来回序列化（例如在 Web 应用程序中）或 Web 服务），而不是更新的对象永远不会与最初检索的对象相同。在这种情况下，它们可以安全地附加到新的 DataContext。

【讨论】：

【解决方案2】：

恕我直言，当业务逻辑层 (BLL) 需要 I/O 到某些存储（DB、XML、磁盘等）时，最好的方法是让数据访问层 (DAL) 脱离 BLL，因为您可以更改它，你想控制缓存等。所以实际上，BLL 不应该有 DataContext，只是与 DAL（接口）的合同。

【讨论】：

【解决方案3】：

与往常一样，这取决于您的具体情况，但作为一个很好的启发式方法，我建议您创建/提交/放弃您的 DataContext（如果您使用 NHibernate，则创建您的 ISession，或者如果您使用 EDM，则创建您的 ObjectContext ) 在您的演示文稿和业务逻辑之间的薄外观中。这有时被称为服务层的应用层。

那是在哪里，现在——如何。另一个很好的启发式方法是您应该使用 AOP 来完成任务。我所说的 AOP 并不是指一个庞大的 AOP 专用框架。几乎所有的表示和 Web 服务框架都提供了一些 AOP 功能，使您能够在执行业务代码之前和之后做一些工作，例如 ASP.NET 中的 IHttpModule 和 WCF 中的 IDispatchMessageInspector。插入您之前的框架并创建 DataContext。

如果您需要更改 DAL，则只需更改 DAL 和用于创建/提交 DAL 更改的代码。事实上，AOP 可注入代码也应该放在 DAL 程序集中，并且如果可能的话，在引导例程中进行配置。

【讨论】：