inheritanceList来实现集合是个坏主意吗？我曾经读过ImaarSpaanjars的一篇关于如何构建3层应用程序的文章。(http://imar.spaanjaars.com/416/building-layered-web-applications-with-microsoft-aspnet-20-part-1)这已成为我编码的基础。所以我通过inheritanceList来实现集合。所以如果我有一个名为Employee的类来实现一个集合，我也会有一个Employees类，如下所示。classEmployee{intEmpID{get;set;}stringEmpName{get;set;}}classEmployees:List{publicEmployees(){}}我从来没有真正质疑过这个，因为它为我完成了工作。但是现在我开始尝试一些事情，我不确定这是否是正确的方法。例如，如果我想从Employees中获取一个子集，例如EmployeesnewEmployees=(Employees)A??llEmployees.FindAll(emp=>emp.JoiningDate>DateTime.Now);这会引发System.InvalidCastException。但是，如果我使用以下内容，则没有问题。ListnewEmployees=AllEmployees.FindAll(emp=>emp.JoiningDate>DateTime.Now);那么我如何实现Employees以便我不必在DAL或BLL中显式使用List呢？或者我怎样才能摆脱InvalidCastexception？我不会inheritList-它引入了类似的问题并且并没有真正帮助（因为没有虚拟方法可以覆盖）。我要么使用List（或更抽象的IList），要么引入多态性，Collection具有虚拟方法。作为说明；使用FindAll之类的东西，您还会找到LINQ选项的有用对应项（例如.Where()）；最值得注意的是，它们适用于任何IList（或IEnumerable），而不仅仅是列表和子类。继承List有什么好处？如果它什么都不添加，那么它就是不必要的代码膨胀。如果您不通过此处未显示的构造函数显示方法或强制执行合同，这可能是子类化的正当理由。在解决转换问题方面，您不能将List转发给Employees，因为List不继承自Employees。如果您需要使用您的条件返回Employees，那么您最好包装调用并将返回的列表项插入您自己的Employees对象。这对我来说似乎是在浪费时间，除非像我上面所说的那样，您有充分的理由将List子类化。就个人而言，我尽可能地尝试使用IList并且除非它们有存在的理由，否则不要子类化。一个简单的经验法则是从COMPOSITION（例如，将Employees包装在一个通用集合中）而不是INHERITANCE开始。从基于继承的设计开始，把自己画到角落里。组合更加灵活和可修改。如果需要为列表本身提供访问者，我个人会将列表存储为容器对象的成员。类MyCollection{列表_table;公共列表表{get{return_table;}}//...所有表通用的其他访问/实用函数//（例如CRUD）}classEmployees:MyCollection{//...还有更多方法}我必须承认我这样做是为了给自己以下内容方法：TFindById(intid)；无效添加（T实体）；voidRemove(T实体);在基类中和：T[]GetEmployeesBy(your_filter_here);我（仍在）使用.net2.0，所以我没有linq-也许这就是它在那里的原因。以上是C#学习教程：IsinheritanceListabadideatoimplementcollections?如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
