When defining a WCF data contract, which type should one use for collections/lists?
- Should it be ICollection<T>, IList<T>, T[] or…?
- Should I use interface types or the concrete types?
- What trade offs are there to consider?
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
note: I’m answering this from the client’s perspective – i.e. the
/collectionType:<type>switch onsvcutil.exe(also available in the IDE).Personally, I tend to keep it simple and use
List<T>. If you are going to do lots of data binding,BindingList<T>might be an option, but for object properties it is usually overkill. Arrays make life very hard… avoid them ;-pNote that with .NET 3.5 the features available to each collection type blur, thanks to the extension methods on
Enumerable.Normally,
Collection<T>is useful when you think you might want to subclass the collection to use thevirtualextension points. This isn’t really an option with WCF.As already stated, using
IList<T>etc isn’t an option unless you are using assembly sharing, since the generated class won’t be able to create the collection.