Use Singleton pattern for LINQ to SQL persistance - good idea?

I have a table, Users, with a related child table, UserSecurityGroups. In my GUI, the operator would select a user from a list. The program would retrieve the user record and allow the operator to edit the user data in one form. The operator could also edit the UserSecurityGroups of this user on another form.

I am considering using a singleton 开发者_StackOverflow社区class for user instance retrieval and persistance back to the database. If this is a good practice, I want to use this with many other tables in my DB. My question is: Is this a good practice? What pitfalls am I missing? What would you recommend as an alternative? Would your recommendation change since I also have tables with three or four levels of relations (as opposed to two in the example above)?

Here is my proposed code:

Imports System.Data.Linq

Public Class UserConduit
    Implements IDisposable

    Private Shared _thisUserConduit As UserConduit
    Private Shared _thisContext As VulcanDataContext

    Protected Sub New()
        _thisContext = New VulcanDataContext
    End Sub

    Public Shared Function GetInstance()

        If _thisUserConduit Is Nothing Then
            _thisUserConduit = New UserConduit
        End If

        Return _thisUserConduit

    End Function

    Public Function GetUserByID(ByVal thisUserName As String) As User

        Return _thisContext.Users.SingleOrDefault(Function(u) u.Username = thisUserName)

    End Function

    Public Function Save() As ChangeSet

        Dim thisSet = _thisContext.GetChangeSet

        Try
            _thisContext.SubmitChanges()

        Catch ex As Exception
            Throw

        End Try

        Return thisSet

    End Function

    Public Function Save(ByVal thisUser As User) As ChangeSet

        If thisUser.Modified Is Nothing Then
            _thisContext.Users.InsertOnSubmit(thisUser)
        End If

        Return Save()

    End Function


#Region " IDisposable Support "
    Private disposedValue As Boolean = False        ' To detect redundant calls

    ' IDisposable
    Protected Overridable Sub Dispose(ByVal disposing As Boolean)
        If Not Me.disposedValue Then
            If disposing Then
                ' free other state (managed objects).
                _thisContext.Dispose()
            End If

            ' free your own state (unmanaged objects).
            ' set large fields to null.
        End If
        Me.disposedValue = True
    End Sub


    ' This code added by Visual Basic to correctly implement the disposable pattern.
    Public Sub Dispose() Implements IDisposable.Dispose
        ' Do not change this code.  Put cleanup code in Dispose(ByVal disposing As Boolean) above.
        Dispose(True)
        GC.SuppressFinalize(Me)
    End Sub
#End Region

End Class

Singleton is generally considered an anti-pattern these days. Which is not to say that there aren't situations where you want to guarantee there's only one instance of a particular type ... but a better solution is to use an inversion-of-control (IoC) container such as StructureMap to wrap your type in a singleton. I believe the Policy Injection block of Enterprise Library will also do this.

In my experience LINQ to SQL is limited in what you can do as far as handling relationships ... you can easily end up incurring an additional query for each related table. We are looking at moving to NHibernate as the additional queries are becoming a performance issue.