如何解决使用Singleton模式进行LINQ to SQL持久性-好主意吗?
| 我有一个表Users,带有相关的子表UserSecurityGroups。在我的GUI中,操作员将从列表中选择一个用户。该程序将检索用户记录,并允许操作员以一种形式编辑用户数据。操作员还可以在另一个表单上编辑此用户的UserSecurityGroups。 我正在考虑使用单例类进行用户实例检索并将其持久化回数据库。如果这是一个好习惯,那么我想将其与数据库中的许多其他表一起使用。我的问题是:这是一种好习惯吗?我错过了什么陷阱?您会推荐什么替代方案?因为我也有包含三个或四个关系级别的表(与上面示例中的两个相对),您的建议会改变吗? 这是我建议的代码: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
解决方法
如今,单例通常被认为是反模式。这并不是说在任何情况下都不想保证只有一个特定类型的实例...但是更好的解决方案是使用控制反转(IoC)容器,例如StructureMap将您的类型包装为单例。我相信企业库的策略注入模块也可以做到这一点。
以我的经验,LINQ to SQL在处理关系方面只能做些限制...您很容易最终为每个相关表产生一个附加查询。随着其他查询成为性能问题,我们正在考虑迁移到NHibernate。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。