Question

ORMs often map one-to-many relationships such as:

class Parent {
   IList<Child> Children { get; set; }
}

The problem is that in the repository, you may have:

GetChildrenOfParent(int parentID) {
   from c in Children...

   return children;
}

You now have two places to “get” children. When you want to add something, such as maybe only return children who do not have a deleted flag, you might have:

GetChildrenOfParent(int parentID) {
    from c in Children..
    where not deleted

    return children;
}

or

class Parent {
   IList<Child> Children { get .... only get not deleted children; set; }
}

Do you see what I am getting at? You now have two places in which to choose to perform the getter routine. It seems that the logical place to have this routine is in the repository, yet that means that:

foreach (var child in parent.Children)

is not going through your “getter” anymore, hence the whole idea of the ORM having one-to-many mapped this way seems to be wrong?

Answer 1

I’m not really sure what your question is but I don’t really see where it is ‘wrong’. It comes down to design choice IMO. Do you want to access hierarchical data (child entities) from each entity. If you do and you want to load that data in on an initial fetch then utilising the one to many is a time saver (you can opt to pre load it or lazy load it). In that case fetching your data in the first example may be a good for you. You can use LINQ to filter the data to only bring back ‘non deleted’ results or ‘whatever filter you need’ like so:

IList<Child> list = parent.Children.Where(x => x.Deleted == false);

Personally, I like to keep it clean and, when I’m using the repository pattern (I’m becoming a big fan of the ActiveRecord Pattern lately). I prefer to seperate this out into it’s own method call. You could add the repository call into a property name children but then, for me, that feels like I’m crossing boundaries between have a model and where I’m hyrdating that model.

But doing it that way sometimes ends you up with a whole bunch of methods to do basic filtering or a silly bunch or overloads to manage cases where you want to select say ‘Deleted Or Not’ and ‘Male Or Female’ or just ‘Deleted Or Not’.

As I said, it comes down to choice. How do you want your app to grow, if you think you are ending up with a list of silly overloads in a repository can you make it cleaner so that future coders can understand your code, there’s less code to manage, and it doesn’t interfere with performance (or makes it perform better ideally). In which case having tests will help you refactor without breaking code.

Don’t get hung up on the ‘right’ or ‘wrong’ way of doing things.