Linq to SQL DataContext的用法

Question

我正在创建一个ASP .Net网站，并想对我的数据层使用Linq to SQL类，然后有另一个项目可以为数据层提供服务。 我对Linq to SQL相当陌生。

我拥有的结构是一个接口，该接口在单独的接口中列出了数据库中每个表所需的所有CRUD（创建，读取，更新和删除）操作。

然后，我还有另一个实现接口的类，即我编写所有代码以获取，更新，删除数据等，即

Public Function GetCustomers As Iqueryable(of Customer)
Dim Service as New StoreDataContext
Return From c in Service.Customers select c
End Function

我注意到的是，我总是在所有方法中都将Dim Service As New StoreDataContext编写为对数据进行任何处理。

然后，这导致我思考并在每个类中创建一个属性，并使用数据上下文初始化该属性。 为了更进一步，我想创建一个MustInherit类，以便所有类都可以继承该类，并且需要进行任何更改都可以在一个阶段完成，而不是进入所有类

Public MustInherit Class MyService

    Public ReadOnly Property CurrentDataContext As StoreDataContext
        Get
            Return New StoreDataContext
        End Get
    End Property

End Class

我的客户类别看起来像

Public Class CustomerSer
Inherits MyService
Implements ICustomer

Public Function GetCustomers As Iqueryable(of Customer)
Return From c in CurrentDataContext.Customers select c
End Function

如您所见，上面的函数使用的是CurrentDataContext，它是从创建的类继承的。

问题：

1. 这样可以吗，或者这种设计会有缺陷吗？
2. 我是否需要在任何阶段或在课堂上关闭此服务？

谢谢

Answer 1

每次都应创建一个新的数据上下文，因为您想确定何时发生“提交更改”。 这遵循一种称为Unit Of Work的软件工程模式，您可以在其中打开上下文，对实体树进行大量工作，然后单击Submit。 用一种方法完成所有操作，以便将来任何人都可以清楚了解正在发生的事情。

如果将创建内容移到属性中，则不清楚提交更改在何处生效。 您可以打开一种方法，另一种进行一些更改，第三种然后进行提交更改，然后另一种进行更多然后未提交的更改，这将很难检测到。

我知道这看起来像样板，不是DRY（不要重复自己），但仍然是良好的编程习惯。

这是Scott Guthrie撰写的有关使用Submit Changes的更详细的很好的解释。