继承List <T>来实现集合是个坏主意吗？

Question

我曾经读过Imaar Spaanjars关于如何构建3层应用程序的文章.(http://imar.spaanjaars.com/416/building-layered-web-applications-with-microsoft-aspnet-20-part-1)这已成为我编码的基础.

因此,我通过继承a来实现集合List<T>.因此,如果我有一个名为Employee的类,要实现一个集合,我还将有一个Employees类,如下所示.

class Employee
{
   int EmpID {get;set;}
   string EmpName {get;set;}  

}

class Employees : List<Employee>
{
   public Employees(){}
}

我从来没有真正质疑这一点,因为它为我做了工作.但是现在我开始尝试一些事情,我不确定这是否是正确的方法.

例如,如果我想从Employees获得一个子集,例如

 Employees newEmployees = (Employees) AllEmployees.FindAll(emp => emp.JoiningDate > DateTime.Now);

这会抛出System.InvalidCastException.但是,如果我使用以下内容则没有问题.

List<Employee> newEmployees = AllEmployees.FindAll(emp => emp.JoiningDate > DateTime.Now);

那么我该如何实现Employees以便我不必List<Employee>在DAL或BLL中明确使用？或者我怎么摆脱InvalidCastexception？

Answer 1

我不会继承List<T>- 它引入了这样的问题,并没有真正帮助(因为没有virtual方法可以覆盖).我要么使用List<T>(或更抽象IList<T>),要么引入多态Collection<T> 有虚拟方法.

作为一个笔记; 重要的是FindAll,你也可以找到LINQ选项(比如.Where())有用的对应物; 最值得注意的是,它们适用于任何 IList<T>(或IEnumerable<T>),而不仅仅是List<T>子类.

Answer 2

通过子分类获得了什么好处List<Employee>？如果它没有添加任何内容,那么它就是不必要的代码膨胀.如果您没有显示方法或通过您未在此处显示的构造函数强制执行合同,则可能是进行子类化的正当理由.

在解决您的投射问题方面,您不能从a转发为a List<Employee>,Employees因为List<Employee>不会继承Employees.如果您需要使用您的条件返回Employees,那么您最好封装调用并将返回的列表项插入到您自己的Employees对象中.这对我来说似乎是浪费时间,除非像我上面所说的那样,你有充分的理由去分类List<Employee>.

就个人而言,我会尽可能地尝试使用IList<T>,除非他们有理由存在,否则不要创建子类.