列出<BusinessObject>或BusinessObjectCollection?

在C#generics之前,每个人都可以通过创build一个实现了IEnumerable的集合库来为他们的业务对象编写集合

IE:

public class CollectionBase : IEnumerable 

然后从中得到他们的业务对象集合。

 public class BusinessObjectCollection : CollectionBase 

现在用generics列表类,没有人只是使用它呢? 我发现我使用这两种技术的妥协:

 public class BusinessObjectCollection : List<BusinessObject> 

我这样做是因为我喜欢强types名称,而不是仅仅传递List。

你的方法是什么?

我通常在直接使用List的阵营,除非由于某种原因,我需要封装数据结构,并提供其function的有限子集。 这主要是因为如果我没有特殊的封装需求,那么这样做只是浪费时间。

但是,使用C#3.0中的聚合初始化function,我会提倡使用自定义集合类的一些新情况。

基本上,C#3.0允许任何实现了IEnumerable类,并且有一个Add方法来使用新的聚集初始化语法。 例如,因为Dictionary定义了一个方法Add(K key,V value),所以可以用下面的语法初始化一个字典:

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

关于这个特性的好处是,它可以用于任意数量参数的添加方法。 例如,给定这个集合:

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

可以像这样初始化它:

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

如果您需要创build复杂对象的静态表,这可能非常有用。 例如,如果您只是使用List<Customer>并且想要创build一个客户对象的静态列表,则必须像这样创build它:

 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") } 

但是,如果您使用自定义集合,如下所示:

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

您可以使用以下语法初始化集合:

 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"} } 

这样做的好处是既易于input又易于阅读,因为它们不需要为每个元素重新input元素types名称。 如果元素types长或复杂,则优点可以特别强。

这就是说,只有当你需要在你的应用程序中定义的静态数据集时,这才是有用的。 某些types的应用程序(如编译器)始终使用它们。 其他的,像典型的数据库应用程序不会因为他们加载数据库中的所有数据。

我的build议是,如果你需要定义一个静态的对象集合,或者需要封装集合接口,那么创build一个自定义集合类。 否则,我会直接使用List<T>

build议在公共API中不要使用List <T>,而要使用Collection <T>

如果你从它inheritance,你应该没问题,afaik。

我宁愿只使用List<BusinessObject> 。 键入它只是给代码添加了不必要的样板。 List<BusinessObject>是一个特定的types,它不仅仅是任何List对象,所以它仍然是强types的。

更重要的是,声明List<BusinessObject>使每个读取代码的人都可以更容易地知道他们正在处理的是哪些types,他们不需要search以找出BusinessObjectCollection是什么,然后记住它只是一个列表。 通过typedefing,你必须要求一个一致的(重新)命名约定,每个人都必须遵循才能使其有意义。

使用typesList<BusinessObject> ,您必须声明它们的列表。 但是,如果返回BusinessObject列表,请考虑返回IEnumerable<T>IList<T>ReadOnlyCollection<T> – 即返回满足客户端的最弱可能合约。

您想在列表中添加自定义代码的位置,列表types上的代码扩展方法。 再次,将这些方法附加到最弱的合同,例如

 public static int SomeCount(this IEnumerable<BusinessObject> someList) 

当然,你不能也不应该用扩展方法添加状态,所以如果你需要添加一个新的属性和后面的字段,使用一个子类或更好的包装类来存储这个。

我一直在两个选项之间来回走动:

 public class BusinessObjectCollection : List<BusinessObject> {} 

或者只是执行以下操作的方法:

 public IEnumerable<BusinessObject> GetBusinessObjects(); 

第一种方法的好处是,您可以更改底层数据存储,而不必混淆方法签名。 不幸的是,如果你从一个集合typesinheritance,那么这个集合types会从前面的实现中移除一个方法,那么你将不得不在整个代码中处理这些情况。

您应该避免为此目的创build自己的集合。 在重构过程中或者在添加新的特性时,想要多次改变数据结构的types是很常见的。 通过您的方法,您可以为BusinessObjectList,BusinessObjectDictionary,BusinessObjectTree等单独分类。

我真的没有看到创build这个类的任何价值,因为类名更具可读性。 是的,尖括号的语法是丑陋的,但它是C ++,C#和Java的标准,所以即使你不写代码使用它,你会一直运行它。

我做的和Jonathan完全一样…只是从List<T>inheritance。 你得到两全其美。 但是我通常只在添加一些值的时候才会这样做,比如添加一个LoadAll()方法等等。

如果我需要“增加价值”,我通常只会派生自己的集合类。 就像,如果集合本身需要有一些“元数据”属性标记。

你可以使用两者。 对于懒惰 – 我的意思是生产力 – 列表是一个非常有用的类,它也是“全面的”,并坦率地充满了YANGNI成员。 再加上MSDN文章中提出的关于公开成员暴露List的明智论据/build议,我更喜欢“第三种”方式:

就我个人而言,我使用装饰模式,只暴露我需要从列表即:

 public OrderItemCollection : IEnumerable<OrderItem> { private readonly List<OrderItem> _orderItems = new List<OrderItem>(); void Add(OrderItem item) { _orderItems.Add(item) } //implement only the list members, which are required from your domain. //ie. sum items, calculate weight etc... private IEnumerator<string> Enumerator() { return _orderItems.GetEnumerator(); } public IEnumerator<string> GetEnumerator() { return Enumerator(); } } 

更进一步,我可能会抽象OrderItemCollection到IOrderItemCollection,所以我可以交换IOrderItemCollection在未来的实现(我可能更喜欢使用不同的内部可枚举对象,如集合或更喜欢使用一个键值对集合或集。

几乎所有的场景都使用generics列表。 我只考虑使用派生集合的唯一时间是如果我添加特定于集合的成员。 然而,LINQ的出现减less了甚至需要。

1,6,6,另一半

无论哪种方式是同样的事情。 我只有当我有理由将自定义代码添加到BusinessObjectCollection时才这样做。

没有它的加载方法返回一个列表允许我写一个共同的generics类更多的代码,并只是工作。 比如一个Load方法。

正如别人指出的那样,build议不要公开暴露列表,如果你这样做,FxCop会鸣叫。 这包括从Listinheritance,如下所示:

 public MyTypeCollection : List<MyType> 

在大多数情况下,公共API将酌情公开IList(或ICollection或IEnumerable)。

如果你想要自己的自定义集合,可以通过从Collection而不是List来inheritanceFxCop。

如果您select创build自己的集合类,则应该检出System.Collections.ObjectModel Namespace中的types。

命名空间定义了基类,使实现者更容易创build自定义集合。

如果我想屏蔽实际列表的访问权限,我倾向于使用我自己的collections集。 当你写业务对象的时候,很有可能你需要一个钩子来知道你的对象是被添加还是删除了,这样的话我觉得BOCollection是个好主意。 如果不需要的话,List是更轻量级的。 另外,如果您需要某种代理(例如,假集合触发数据库的延迟加载),则可能需要检查使用IList来提供更多的抽象接口,

但是…为什么不考虑Castle ActiveRecord或任何其他成熟的ORM框架? 🙂

在大多数情况下,我只需要使用List方法,因为它在90%的时间内为我提供了所需的所有function,当需要“额外”时,我从它inheritance,然后编写额外的位。

我会这样做:

 using BusinessObjectCollection = List<BusinessObject>; 

这只是创build一个别名,而不是一个全新的types。 我更喜欢直接使用List <BusinessObject>,因为它使我可以在将来的某个时候自由地更改集合的底层结构,而不必更改使用它的代码(只要我提供相同的属性和方法)即可。

试试这个:

 System.Collections.ObjectModel.Collection<BusinessObject> 

不需要像CollectionBase那样实现基本的方法

这是方式:

返回数组,接受IEnumerable<T>

=)