I also use my own custom collections. The reason to do this instead of using arraylists, datasets/datatables, etc. is that I can strongly type my collections. No chances that I will screw anything up in that department. Plus, because it is strongly typed, I then can do better databinding if I wish. Imagine this:

You have a list box. You want to bind a set of users to the listbox. The requirement is to show the user name in the list box as Lastname, Firstname.

Now, you could create a custom procedure in the database to do this, but then your procedure would be tied only to this instance of code that uses it. Seems like a waste since there are other things we do with user data in our application, and we already have a select stored procedure written. Plus you would be working with a datatable most likely and have to specify database column names to bind to in the UI. That is bad design.

Since I am working in a object oriented fashon, I have a user object already that exposes a FirstName property as well as a LastName property. It has a load method that calls the more generic select procedure to load the properties of the object from the database. I can easily add a property to this object called something like WholeName that returns the concated name. I bind to this property super easily, and the end result was an additional 2-3 lines of code.

If I wouldn't have done this, then I would have had the stored procedure code and any other plummng to get that returned dataset binded to the control.

I don't know if that makes sense. It is harder for me to explain than to just show you. Maybe sometime I will do up a full blown example on this subject.