对Ilist和List的一点总结，摘抄别人的

// 比如我们要对用户信息进行管理 // 可以先定义一个用户信息类,只加一个字段 public class UserInfo {    private string _name;    public int Name{ get { return _name;} set { this ._name = value;}}    public UserInfo(){}    public UserInfo( string name){ this .Name = name;} } // 再定义一个逻辑操作类 public class User {    // 如果我要取得用户信息我们不必返回数据库里的dataset或datareader    // 使用泛类型    public IList < UserInfo > GetUsers()    {       IList < UserInfo > user = new List < UserInfo > ();      SqlDataReader dr = sqlhelper.GetUsers(); // 调用数据层        while (dr.Read())      {         UserInfo ui = new UserInfo(dr[ " UserName " ].ToString());         user.Add(ui);      }      return user;    }    } 以后我得到的都是UserInfo实例的集合，并且这些集合里都已经包含了数据，在操作的时候我们可以new User.GetUser()[0].Name来读取第一条数据的用户名，这样在表现层里就不需要操作dataset和datareader等数据对象了，表现层里看到的都是一个个对象实例，当然在userinfo字段少的时候看不到什么优点，但是在如果表里字段多的时候，效果就体现了，想取哪个字段的值，直接（对象．字段名）得到，看起来不是很舒服，很简洁么？ 在封装方面来说，这样可以使程序更模块化！ 本人表达能力估计差了点，想说得明白些也说不清楚，我的用法是如果一个表使用的非常频繁，而且需要提取的字段比较多，就把该表模块化，定义成一个模块实体，表中每个字段定义成类的属性，同时再定义一个操作此模块的操作类（也就是逻辑层了），这个类的所有对模块（也就是表）操作所需要的参数，都直接用模块实体来代替，比如我们可能用函数DeleteUser(int userid)根据一个用户id来删除一个用户，现在我们不这样做直接根据一个实体来删除如DeleteUser(UserInfo ui)这样在表现层看到的只是实体和对象！这种方法在设计模式中会用得比较多，我们开发过的大多程序都是这样做的，往往能做到避免一边写程序一边看数据表结构的苦恼！     嗯，我把“我是想知道为什么不在数据层定义一个实体类”这句话重新理解为“我是想知道为什么不在数据层定义一个实体类的强类型集合”吧！ 你完全可以自定义，这样你既可以简单地从List<T>继承，也可以定义ILIst<T>接口并手工实现各个方法。 而实际上，大多数人为了简单化，可能会很自然地从List<T>继承的，而不会相当“痛苦”地手写那些IList<T>接口实现。不过既然List<T>也是实现了IList<T>接口的，那么写IList<T>就也可以直接用于List<T>。 c#这类不支持多重继承的语言工具在处理稍微复杂的继承时比较烦（我喜欢没有interface只有继承的纯粹面向对象语言，不过在.net上只能迁就c#）。写c#代码时编程者可能根据经验想到自定义类型集合往往不一定从List<T>继承。   List类是实现了Ilsit的接口。接口做为返回值返回的是实现了这个接口的对象。正真正开发中她们作为返回类型是没有太大区别的。

转载于:https://www.cnblogs.com/gaoxuzhao/archive/2011/10/20/2218580.html