Linq to SQL DataContext的用法

Question

I am creating an ASP .Net website and would like to use Linq to SQL class for my datalayer then have another project which would service the datalayer. Im fairly new with Linq to SQL.

The structure i have is an Interface which lists all the CRUD (Create, Read, Update and Delete) operations i need for each table in the database in a separate Interface.

I then have another class which implements the Interface were i write all my code to get, update, delete data etc ie

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

What i noticed was i was always writing Dim Service As New StoreDataContext in all my methods in order to do anything with my data.

This then led me to think and create a property in each class which initialises the property with a datacontext. To go one step better i thought to create a MustInherit class so all the classes would then inherit this class and any changes need to be made could be done at one stage rather than going into all the classes

Public MustInherit Class MyService

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

End Class

My customer class would look like

Public Class CustomerSer
Inherits MyService
Implements ICustomer

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

As you can tell the function above is using CurrentDataContext which is being Inherited from the class created.

Questions:

1. Is this ok or would there be some flaw in this design?
2. Do i need to close this service at any stage or in my class?

Thanks

Answer 1

You should create a new data context each time because you want to be sure when Submit Changes occurs. This follows a software engineering pattern called Unit Of Work , where you open a context, do a bunch of work to the tree of entities and then hit submit. Do that all in one method so that it is nice and clear for anyone in the future to understand what is going on.

If you move the create into a property, it is not as clear where the submit changes takes affect. You could have one method open it, another make some changes, a third then do Submit Changes and then another do some more changes that are not then submitted, which will be difficult to detect.

I know that this looks like boilerplate, isn't DRY (Don't repeat yourself) but is still good programming practise.

Here's a nice explanation in more detail about using Submit Changes by Scott Guthrie .