对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的接口。接口做为返回值返回的是实现了这个接口的对象。正真正开发中她们作为返回类型是没有太大区别的。