Question

我有一个问题要决定我的系统中哪个层应该创建DataContext。我读过一本书，说如果没有为所有人传递相同的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

Answer 1

将DataContext紧密耦合到LINQ to SQL，你绝对应该在DAL中创建它。

看看我提供给somewhat related SO question的答案。它带来了同样的问题，即DataContext（实体框架中的ObjectContext）是应该在多个数据库操作中保持活动，还是应该创建并处理它。

您提到的问题与 model objects retrieved through a DataContext can only be updated using the same DataContext instance 这一事实有关。现在，如果已经处理了原始DataContext，那么将更新的模型对象附加到新的DataContext实例的任何尝试都将失败。

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

Answer 2

恕我直言，当业务逻辑层（BLL）需要I / O到一些商店（数据库，XML，磁盘等）时，最好的方法是从BLL中获取数据访问层（DAL），因为你可以改变它，你想控制缓存等等。实际上，BLL不应该有DataContext，只是与DAL（接口）签订合同。

Answer 3

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

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

如果您需要更改DAL，则必须仅更改DAL以及用于创建/提交DAL更改的代码。实际上，AOP可注入代码也应该放在DAL程序集中，如果可能的话，也可以在自举程序中进行配置。

哪个层应该创建DataContext？

3 个答案: