Circular Dependencies.

[Henry Miller]

I have the following code (much simplified for this post). Note that
SessionKey uses DataAccess, and DataAccess requires SessionKey in it's
constructor.

Public Class SessionKey
Public IsValidSession as Boolean

Sub New(UserName, Password)
' Create session, including calls on DataAccess
' to validate username/password

IsValidSession = True
Dim DataAccess as New DataAccess(Me)

' Set IsValidSesion = False if usercode/password is invalid.

End Sub
End Class

Public Class DataAccess
Sub New(SessionKey)
If Not SessionKey.IsValidSession then
Throw New Exception ("Not a valid session!")
End If
End Sub

Function ExecuteSQL(SQL) As DataSet
'execute some SQL

End Function

End Class

It works great, but does this qualify as a circular dependency?
What's wrong with having a circular dependency in the first place?
Memory leaks? Performance problems? I understand that circular
dependencies can be a symptom of poorly designed class libraries, but
in this case, the class design seems fine. Should I take the time to
create a 3rd class that SessionKey and DataAccess inherit from?

Thanks,

Henry

 

[Michael Giagnocavo [MVP]]

If you don't mind your class design, then it won't have a problem. Circular
dependencies can be a problem when the classes are in different assemblies.
Circular references used to be more a problem, but the GC handled them just
fine now. A recursive call might result in your classes if someone isn't
careful (suppose in one constructor, you call the other, and vice versa) --
however those will result in a stack overflow after taking full CPU for a
bit, so they'll be noticed when they happen.

-mike
MVP