工厂模式中为什么要用IList和List泛型?

Question

我下载了很多三层结构的代码,发现它们都大量使用了泛型,
数据层:public IList<ItemInfo> GetItemByNew()
        {            IList<ItemInfo> item = new List<ItemInfo>();
            using (SqlDataReader dr = SQLHelper.ExecuteReader(SQLHelper.txtConnecttionString, CommandType.StoredProcedure, "SelectItemByNew", null))
            {
                while (dr.Read())
                {                    ItemInfo itemInfo = new ItemInfo(dr.GetInt32(0), dr.GetString(1), dr.GetDecimal(2), dr.GetDecimal(3), dr.GetDecimal(4), dr.GetString(5));
                    item.Add(itemInfo);
                }
            }
            return item;        }
业务层:
public IList<ItemInfo> GetItemByNew()
        {            return dal.GetItemByNew();        }
表示层:
IList<ItemInfo> item = bll.GetItemByNew();
为什么要使用IList接口呢?直接用它的类不是更简单吗?
谁有这方面的资料请推荐一下,谢谢!

Answer 1

够用就好。List比ILIst更大更复杂一些。

Answer 2

http://www.cnblogs.com/zgqys1980/archive/2007/08/30/876043.html 看看

Answer 3

通俗说IList比List范围大些，这样如果一个方法参数是IList那么肯定能用List,很多时候用这种方法来方便扩展

Answer 4

IList 泛型接口是 ICollection 泛型接口的子代，
执行效果好并且是类型安全的

Answer 5

底层数据结构改成其它的容器，只要这个容器支持IList，就不会影响调用值。也就是所谓的依赖倒转:依赖倒转原则A.高层模块不应依赖低层模块，两个都应该依赖抽象。B.抽象不应依赖细节，细节应该依赖抽象。说白了就是要针对接口编程，不要对是想编程。

Answer 6

Ilist主要是用来扩展,其实大部分用list,功能差不多,
用泛类型主要是返回一个集合!
IList<ItemInfo> 表示返回的是ItemInfo对象的集合,
在编程的时候使用起来更加方便!

Answer 7

问题补充:好像我没有讲清楚:我不是想问IList和List之间的差别,我是想知道为什么不在数据层定义一个实体类,直接将类的实例返回,而要故弄玄虚的用IList<>,
是为了方便扩展吗?但在表示层获得的集合只是完成一个特定的功能(将数据赋给html标识字符串),这样的话扩不扩展意义不大吧?

Answer 8

其实就是接口宽窄的问题,
目前看起来，这个方法的消费者只需要返回一个实例,但如果将来需求有变化，需要你返回一个IList,那么你就需要再去改一次代码了。
实际上，是否一定要返回一个collection,直接的原因是你的需求变更的可能性。

Answer 9

其实刚才大家都回答你了,主要是编程方便和好管理了://比如我们要对用户信息进行管理//可以先定义一个用户信息类,只加一个字段
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;
   }
   
}

Answer 10

骑驴找驴了吧。“实体类”这个不生活化的概念念得走火入魔了。实际上，ILIst<T>泛型中的类型参数T在应用中不正是返回的数据个体的类型么？

Answer 11

以后我得到的都是UserInfo实例的集合，并且这些集合里都已经包含了数据，在操作的时候我们可以new User.GetUser()[0].Name来读取第一条数据的用户名，这样在表现层里就不需要操作dataset和datareader等数据对象了，表现层里看到的都是一个个对象实例，当然在userinfo字段少的时候看不到什么优点，但是在如果表里字段多的时候，效果就体现了，想取哪个字段的值，直接（对象．字段名）得到，看起来不是很舒服，很简洁么？在封装方面来说，这样可以使程序更模块化！

Answer 12

嗯，我把“我是想知道为什么不在数据层定义一个实体类”这句话重新理解为“我是想知道为什么不在数据层定义一个实体类的强类型集合”吧！你完全可以自定义，这样你既可以简单地从List<T>继承，也可以定义ILIst<T>接口并手工实现各个方法。而实际上，大多数人为了简单化，可能会很自然地从List<T>继承的，而不会相当“痛苦”地手写那些IList<T>接口实现。不过既然List<T>也是实现了IList<T>接口的，那么写IList<T>就也可以直接用于List<T>。c#这类不支持多重继承的语言工具在处理稍微复杂的继承时比较烦（我喜欢没有interface只有继承的纯粹面向对象语言，不过在.net上只能迁就c#）。写c#代码时编程者可能根据经验想到自定义类型集合往往不一定从List<T>继承。

Answer 13

本人表达能力估计差了点，想说得明白些也说不清楚，我的用法是如果一个表使用的非常频繁，而且需要提取的字段比较多，就把该表模块化，定义成一个模块实体，表中每个字段定义成类的属性，同时再定义一个操作此模块的操作类（也就是逻辑层了），这个类的所有对模块（也就是表）操作所需要的参数，都直接用模块实体来代替，比如我们可能用函数DeleteUser(int userid)根据一个用户id来删除一个用户，现在我们不这样做直接根据一个实体来删除如DeleteUser(UserInfo ui)这样在表现层看到的只是实体和对象！这种方法在设计模式中会用得比较多，我们开发过的大多程序都是这样做的，往往能做到避免一边写程序一边看数据表结构的苦恼！

Answer 14

例如，你可以写一个类型：public class ItemInfoArray : IList<ItemInfo>
{................ 接下来手工实现ILIst的各个方法。
这也可以。不论你是返回一个自定义集合类型，还是返回List<ItemInfo>，使用IList<ItemInfo>作为返回的接口定义都是“通吃”的。当然，其实使用List<ItemInfo>也没有什么，除非你一定要兼容自定义集合类型。

Answer 15

我怀疑你可能刚刚接手你们的软件（以前是别人写的）。你的问题中的程序明明是返回一个 UserInfo 类型对象的集合，你怎么能用 DeleteUser(UserInfo ui) 这个跟集合无关的方法来说明你的问题中的程序和呢？

Answer 16

DeleteUser(string userId)这样更好一点吧。

Answer 17

性能不是一个档次的，你看看我的测试结果，就明白了
http://hi.baidu.com/ucfar/blog/item/5138aa314309f593a9018e5e.html