views:

95

answers:

2

I am on the fence about this question. Is it better to hold a collection of IDs related to an object or a collection of the object relation. I plan to use a repository approach as well. Here is what I mean:

public class Person
{
     string PersonName {get; set;}
     List<PersonFriend> PersonFriends {get; set;}
{

or...

public class Person
{
     string PersonName {get; set;}
     List<int> PersonFriendIds {get; set;}
{
+3  A: 

As with all great programming endeavors, I believe the answer will wind up being "it depends", based on a number of factors in your environment.

However, I really, really dislike exposing IDs (which, as in your example, are ints) from my data access layer/ORM. So if all other factors are equal, I would prefer the first example.

Now, I'll also say you never really want to make that setter on PersonFriends public. Your DAL/ORM should be populating the backing store and client callers should only be able to get a read-only version of that list.

Jesse C. Slicer
actaully, the PersonFriends example would not be public. The repo and essence will handle the relation. Thanks for pointing htat out!
DDiVita
+5  A: 

Its usually better to go with object relations. That way you're not forcing other classes that use the PersonFriends list to know about the whole repository thing giving you a cleaner separation of domain logic and your data access code.

If you don't want the complete collection of friends loaded into memory you're probably better off not giving the Person class a PersonFriends list at all and just implementing a GetFriendsFor(Person person) method on the repository.

Another solution would be to use an ORM that supports lazy loading to give you the opportunity to load the friends list on demand.

Mendelt
I don't think it would be a complete list, but some subset of the collection. I just wanted to get some opinions about this. Good thoughts!!! thanks
DDiVita