List or BusinessObjectCollection?

Question

Prior to C# generics, everyone would code collections for their business objects by creating a collection base that implemented IEnumerable

IE:

publi         


        

Answer 1

6 of 1, half dozen of another

Either way its the same thing. I only do it when I have reason to add custom code into the BusinessObjectCollection.

With out it having load methods return a list allows me to write more code in a common generic class and have it just work. Such as a Load method.

Answer 2

You should probably avoid creating your own collection for that purpose. It's pretty common to want to change the type of data structure a few times during refactorings or when adding new features. With your approach, you would wind up with a separate class for BusinessObjectList, BusinessObjectDictionary, BusinessObjectTree, etc.

I don't really see any value in creating this class just because the classname is more readable. Yeah, the angle bracket syntax is kind of ugly, but it's standard in C++, C# and Java, so even if you don't write code that uses it you're going to run into it all the time.

Answer 3

I generally only derive my own collection classes if I need to "add value". Like, if the collection itself needed to have some "metadata" properties tagging along with it.

Answer 4

I use generic lists for almost all scenarios. The only time that I would consider using a derived collection anymore is if I add collection specific members. However, the advent of LINQ has lessened the need for even that.

Answer 5

I tend to do it with my own collection if I want to shield the access to the actual list. When you are writing business objects, chance is that you need a hook to know if your object is being added/removed, in such sense I think BOCollection is better idea. Of coz if that is not required, List is more lightweight. Also you might want to check using IList to provide additional abstraction interface if you need some kind of proxying (e.g. a fake collection triggers lazy load from database)

But... why not consider Castle ActiveRecord or any other mature ORM framework? :)

Answer 6

Use the type List<BusinessObject> where you have to declare a list of them. However, where you return a list of BusinessObject, consider returning IEnumerable<T>, IList<T> or ReadOnlyCollection<T> - i.e. return the weakest possible contract that satisfies the client.

Where you want to "add custom code" to a list, code extension methods on the list type. Again, attach these methods to the weakest possible contract, e.g.

public static int SomeCount(this IEnumerable<BusinessObject> someList)

Of course, you can't and shouldn't add state with extension methods, so if you need to add a new property and a field behind it, use a subclass or better, a wrapper class to store this.