tags:

views:

1347

answers:

3

migrating an app from 1.1 to 2.0. should i remove all uses of collectionbase.. if so what is the best strategy for migration.

+12  A: 

Yes, the best classes to look at are in System.Collections.Generic.
I usually use List.

There are two approaches you can use either:

A

public class MyClass
{
  public List<MyItem> Items;
}

B

public class MyItemCollection : List<MyItem>
{
}

public class MyClass
{
  public MyItemCollection Items;
}

The two approaches only differ very slightly and you only need to use method (B) if you plan on extending the functionality of List.

Here's a link with more info:
http://msdn.microsoft.com/en-us/library/6sh2ey19(VS.80).aspx

With regards to the classes that you've already implemented, you can remove all of the functions which are specified in the IList interface. e.g.

public int Add(InstrumentTradeDataRow instTrade) { return List.Add(instTrade); }

This can be removed because List already implements a type safe Add function for you.

See this link for more information:
http://msdn.microsoft.com/en-us/library/3wcytfd1(VS.80).aspx

Mark Ingram
can you give me an example . .
ooo
Done. Anything else you'd like to see?
Mark Ingram
what do i do with existing code like this: public int Add(InstrumentTradeDataRow instTrade) { return List.Add(instTrade); }
ooo
If you are going to do option a... make sure you implement ICollection.
Timothy Khouri
If you want to chaneg the implementation, you should really subclass Collection<T>, otherwise no virtual methods... plus LINQ provides the missing functionality (Find etc) anyway.
Marc Gravell
A: 

I prefer Mark Ingrams A) approach, possibly with a base class you write yourself.

There is another issue with migrating to generics; converting has a tendency to have a certain viral effect. You may find it impossible to stop before you're all the way through. If you THOUGHT you were going to spend a couple of hours doing SOME generics, you'll often find yourself spending several days doing ALL the generics.

You can/should avoid this by giving your new classes operator overloads to/from list

public static implicit operator MyClass(List m) 
{
   // code to convert from m to MyClass
}

public static explicit operator List(MyClass m) 
{
    // code to convert from MyClass list
}

These are really just stopgaps. You can use "find usages" on these at any later stage to determine which places have not been fully converted. When all usages are removed, you can delete the casts.

I generally perfer to make the cast from MyClass to List explicit (this is the way you dont want to go) and the other implicit.

The best approach would then normally be to start at the TOP of your layers, close to the presentation layer and work downwards. (This is opposite of what you might think. If you make the cast from MyClass to List implicit it doesnt matter which end you start)

krosenvold
+4  A: 

Generally, List<T> does most of what you normally want. If you want to customize behaviour, you should inherit from Collection<T> - this has virtual methods so you can tweak behaviour when adding/removing/updating etc. You can't do this with List<T> since there are no (uesful) virtual methods.

Marc Gravell
Unfortunately `Collection<T>.Add` is not virtual though it definitely should be.
abatishchev
@abatishchev - no, but `InsertItem` *is* (which handles `Add` and `Insert`), as is `SetItem` (which handles re-assignment)
Marc Gravell
@Marc: Yea, you're right, I hastened a bit, thanks!
abatishchev