为什么IList<>具有比List<>更少的特征？ [英] Why does IList<> have fewer features than List<>?

问题描述

为了使用 ConvertAll（）这样的功能，我必须将 IList 转换为 List ，这是很痛苦的。

解决方案

请注意 List<> 是具有实际存储的 IList<> c $ c>的实现，即它在后台保存一个数组。一般来说，一个 IList<> 可以代表别的东西。在db4o和linq to sql中，您的 IList<> 可以'指向查询'，即访问列表将触发数据库操作。 通过这种方式，您可以执行 myList.Skip（600）.Take（20）; 来执行分页和只有在这一步才会执行实际的查询。包含一百万条目的 List<> c $ c>将是巨大的，而可能存在 IList<>一个巨大的 Count ，但不要吃大量的内存 - 只要你不访问元素。

ConvertAll 将要求实例化每个对象，因此这是一个代价高昂的操作。因此，最好使操作明确，并强制您检索接口的特定实现。显然，转换要求所有对象都要被实例化，所以懒惰地做这件事没有任何好处。

To use such great function as ConvertAll(), I have to convert IList to List, it's painful.

解决方案

Note that List<> is an implementation of IList<> with actual storage, i.e. it holds an array in the background. In general, an IList<> can be a proxy to something else. In db4o and linq to sql, your IList<> could 'point to a query', i.e. accessing the list will trigger a database operation.

This way, you can perform myList.Skip(600).Take(20); to perform pagination and only in this step will the actual query be executed. A List<> containing a million entries will be huge, while there may be IList<>s that have a huge Count, but don't eat a significant amount of memory - as long as you don't access the elements.

ConvertAll will require each and every object be instantiated so it is a costly operation. Thus, it is better to make the operation explicit and force you to retrieve a specific implementation of the interface. Obviously, conversion requires all objects to be instantiated anyway, so there's no benefit in doing it lazily.

这篇关于为什么IList<>具有比List<>更少的特征？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！