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

As someone else pointed out, it is recommended not to expose List publicly, and FxCop will whinge if you do so. This includes inheriting from List as in:

public MyTypeCollection : List<MyType>

In most cases public APIs will expose IList (or ICollection or IEnumerable) as appropriate.

In cases where you want your own custom collection, you can keep FxCop quiet by inheriting from Collection instead of List.

Answer 2

If you choose to create your own collection class you should check out the types in System.Collections.ObjectModel Namespace.

The namespace defines base classes thare are ment to make it easier for implementers to create a custom collections.

Answer 3

I am generally in the camp of just using a List directly, unless for some reason I need to encapsulate the data structure and provide a limited subset of its functionality. This is mainly because if I don't have a specific need for encapsulation then doing it is just a waste of time.

However, with the aggregate initializes feature in C# 3.0, there are some new situations where I would advocate using customized collection classes.

Basically, C# 3.0 allows any class that implements IEnumerable and has an Add method to use the new aggregate initializer syntax. For example, because Dictionary defines a method Add(K key, V value) it is possible to initialize a dictionary using this syntax:

var d = new Dictionary<string, int>
{
    {"hello", 0},
    {"the answer to life the universe and everything is:", 42}
};

The great thing about the feature is that it works for add methods with any number of arguments. For example, given this collection:

class c1 : IEnumerable
{
    void Add(int x1, int x2, int x3)
    {
        //...
    }

    //...
}

it would be possible to initialize it like so:

var x = new c1
{
    {1,2,3},
    {4,5,6}
}

This can be really useful if you need to create static tables of complex objects. For example, if you were just using List<Customer> and you wanted to create a static list of customer objects you would have to create it like so:

var x = new List<Customer>
{
    new Customer("Scott Wisniewski", "555-555-5555", "Seattle", "WA"),
    new Customer("John Doe", "555-555-1234", "Los Angeles", "CA"),
    new Customer("Michael Scott", "555-555-8769", "Scranton PA"),
    new Customer("Ali G", "", "Staines", "UK")
}

However, if you use a customized collection, like this one:

class CustomerList  : List<Customer>
{
    public void Add(string name, string phoneNumber, string city, string stateOrCountry)
    {
        Add(new Customer(name, phoneNumber, city, stateOrCounter));
    }
}

You could then initialize the collection using this syntax:

var customers = new CustomerList
{
    {"Scott Wisniewski", "555-555-5555", "Seattle", "WA"},
    {"John Doe", "555-555-1234", "Los Angeles", "CA"},
    {"Michael Scott", "555-555-8769", "Scranton PA"},
    {"Ali G", "", "Staines", "UK"}
}

This has the advantage of being both easier to type and easier to read because their is no need to retype the element type name for each element. The advantage can be particularly strong if the element type is long or complex.

That being said, this is only useful if you need static collections of data defined in your app. Some types of apps, like compilers, use them all the time. Others, like typical database apps don't because they load all their data from a database.

My advice would be that if you either need to define a static collection of objects, or need to encapsulate away the collection interface, then create a custom collection class. Otherwise I would just use List<T> directly.

Answer 4

I would do this:

using BusinessObjectCollection = List<BusinessObject>;

This just creates an alias rather than a completely new type. I prefer it to using List<BusinessObject> directly because it leaves me free to change the underlying structure of the collection at some point in the future without changing code that uses it (as long as I provide the same properties and methods).

Answer 5

try out this:

System.Collections.ObjectModel.Collection<BusinessObject>

it makes unnecessary to implement basic method like CollectionBase do

Answer 6

this is the way:

return arrays, accept IEnumerable<T>

=)