Object Oriented Design - object graphs and lookup table data
-
I would like to get some ideas on the best way to handle dealing with data in an object oriented system. Consider: User ======= UserId UserTypeId FirstName LastName OrganizationId UserType =========== UserTypeId Name Organization ============ OrganizationId Name District YearFounded How would you model these database tables with your objects? For simple lookup table data, would User have a property for just UserTypeId or would it have a property of UserType(which includes both Id and Name)? For more complex data, would User have a property for just OrganizationId or would it have a property of Organization? If you go the route of having only an Id as property, how do you manage the display of property data, for instance, when displaying the User in the UI, you still need to display the UserType.Name value, and not just the Id. Would you load and cache a collection of UserType objects and use this to lookup the UserType.Name value when needed? Would it make sense to expose a readonly property User.UserTypeName for convenience that provides the name value? I say readonly since you can edit the Id value, but not the actual UserType name when saving a user. The object graph can grow large with several interactions... what rules do you use to draw the line as to where an object instance and its related graph stop? Thanks for any opinions. Assume the objects must be WCF friendly for use as data contracts.
-
I would like to get some ideas on the best way to handle dealing with data in an object oriented system. Consider: User ======= UserId UserTypeId FirstName LastName OrganizationId UserType =========== UserTypeId Name Organization ============ OrganizationId Name District YearFounded How would you model these database tables with your objects? For simple lookup table data, would User have a property for just UserTypeId or would it have a property of UserType(which includes both Id and Name)? For more complex data, would User have a property for just OrganizationId or would it have a property of Organization? If you go the route of having only an Id as property, how do you manage the display of property data, for instance, when displaying the User in the UI, you still need to display the UserType.Name value, and not just the Id. Would you load and cache a collection of UserType objects and use this to lookup the UserType.Name value when needed? Would it make sense to expose a readonly property User.UserTypeName for convenience that provides the name value? I say readonly since you can edit the Id value, but not the actual UserType name when saving a user. The object graph can grow large with several interactions... what rules do you use to draw the line as to where an object instance and its related graph stop? Thanks for any opinions. Assume the objects must be WCF friendly for use as data contracts.
Firstly, I see no mention in your post of considering the "responsibility" of an object as part of the design process. This indicates your view of Object Oriented Design is far different than mine. If you are asking how to mimic database table structure in your coded structures then that is an entirely different question. The most common method of doing that today is to use one of the many Object Relational Mapping tools to generate the code for you. Of course there are almost always problems associated with them but hey, if all you had to do was click a button then any monkey could do it and we would all be out of work. Many people here on CP seem quite fond of using the new LINQ features in the .NET platform. Don't know if you can use that but if so I recommend looking into it.
-
Firstly, I see no mention in your post of considering the "responsibility" of an object as part of the design process. This indicates your view of Object Oriented Design is far different than mine. If you are asking how to mimic database table structure in your coded structures then that is an entirely different question. The most common method of doing that today is to use one of the many Object Relational Mapping tools to generate the code for you. Of course there are almost always problems associated with them but hey, if all you had to do was click a button then any monkey could do it and we would all be out of work. Many people here on CP seem quite fond of using the new LINQ features in the .NET platform. Don't know if you can use that but if so I recommend looking into it.
Yeah, I guess my question is targeting the classes that might normally be created by an ORM. In our case, they are WCF data contracts, and have no behaviour. The system also has other classes with behaviour, such as a UserBusinessManager class, that exposes methods for working with a User object, to perform actions like Load, Update, Insert, etc.