Data Objects: Compound Objects, Good Idea or not?

ddivita

Member
Joined
May 7, 2008
Messages
19
Programming Experience
10+
I have been developing a pretty large web app and have been using compound data objects. I have had people tell me that it may not be a good idea to use compound objects, but I cannot find anything on the net that tells me why I shouldn't. Here is a small example:

User Object:

VB.NET:
private _userID as integer = 0
private _UserName as string = String.Empty
private _userSecurity as UserSecurityObject = nothing

....all the Public properties associated with the USer Object go here...


UserSecurity Object:

VB.NET:
private _userSecurityID as integer = 0
private _userSecurityLevel as integer = 0
private _userSecurityName as string = String.empty

....all the Public properties associated with the UserSecurityt Object go here...

Personally, I like this approach, but not sure how scalable it is if I ever move to LINQ, which has been on my mind.

I created separate factories to load the individal data similar to this:

VB.NET:
Public Class UserFactory
     Implements iUserFactory
     Public Sub LoadUser(byval user as UserObject)
          ....all the code to load the user object.....
          Call LoadUserSecurity(user.UserSecurity)
     End Sub
End Class

Public Class UserSecurityFactory
     Implments IUserSecurityFactory
     Public Sub LoadUserSecurity(byval userSecurity as UserSecurityObject)
          ....all the code to load the userSecurity object.....
     End Sub
End Class


Any opinions?
 
Back
Top