PetShop4.0－－泛型升级

最新推荐文章于 2025-08-22 11:10:38 发布

plean

最新推荐文章于 2025-08-22 11:10:38 发布

阅读量551

点赞数

分类专栏： C#提高文章标签： string interface path 微软 class 数据库

C#提高专栏收录该内容

137 篇文章

订阅专栏

本文针对PetShop项目的工厂模式和接口策略进行了改进，采用泛型类提高灵活性，支持生成多种类型的对象，并介绍了泛型接口的应用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

http://www.cnblogs.com/viter/archive/2007/12/22/1011095.html

下载“泛型PetShop”源码网络上太多人在研究微软的一个开源项目了，可以用一句话来形容：麻省虽小，五脏俱全！那么这个小小的项目为什么会有那么多的人去议论它呢？它是什么项目呢？
名字叫做PetShop(宠物商店), 它主要体现了微软的三层架构的思想。在此中主要体现为：

这就是微软的三层架构体系，如果还有不懂的朋友，建议上网找找这方面的资料，我在这里就不多说了。PetShop4.0 就是为了让我们这些微软门外汉认识他的三层架构而开源的。下面就是PetShop4.0的主要架构：

以下是各层之间的关系：

因为它的架构不是我这次的重点，所以这里就一笔带过了。这个项目总体来说是不错的，此中利用了工厂模式、策略模式、对象封装（实体类，相当于JavaBean ），面向接口编程及反射等技术。我主要是觉得在工厂模式和接口策略的时候不是很灵活，所以在此基础上作了一些改进：这是原来的DALFactory工厂，主要用于生成DAL接口的对象：

    public class Factory
    {
        public Factory()
        {

        }
        /// <summary>
        /// 返回IDAL.IAuthors的一个对象
        /// </summary>
        /// <returns></returns>
        public IDAL.IAuthors GetIAuthors()
        {
           String dal_authors = ConfigurationManager.AppSettings["DAL_Authors"];
            String path = dal_authors + ".Authors";
            return (IDAL.IAuthors)Assembly.Load(path).CreateInstance("Authors");
        }
    }

可以看到，在这里，想要生成不同的对象，只能再写一个方法。这太不灵活，也影响效率，更要命的是，这个工厂只能生成特定类型的对象。所以，就有了下面的这个升级版：

public class Factory<T>
{

        public Factory()
        {
        }
        /// <summary>
        /// 根据配置文件生成一个传入的对象,并将其转为IDAL.IDALConll泛型接口
        /// </summary>
        /// <returns>IDAL.IDALConll</returns>
        public static IDAL.IDALConll<T> GetIDAL(String path, String Obj)
        {
            return (IDAL.IDALConll<T>)Assembly.Load(path).CreateInstance(Obj);
        }
    }

其实只作了一点改进，应用了泛型类，就已经使得原来只能生产一种对象的方法变成了可生成多种类型的方法，不管你有多少种，只要你传入<T>类型就可了，，而且在工厂里读取配置文件并不是一件令人愉快的事，所以这里改为方法里的参数接收；其实这里的作用是基于接口的，泛型工厂的产生是为了泛型接口，如果泛型接口不存在，那泛型工厂也没有存在的意义了，来看一下下面的代码：

    public interface IAuthors
    {
        /// <summary>
        /// 返回Authors实体类的集合
        /// </summary>
        /// <param name="ID"></param>
        /// <returns></returns>
        IList<Model.Authors> GetItemByAuthors(String qureystring);

        /// <summary>
        /// 返回Authors实体类单个对象
        /// </summary>
        /// <param name="ID"></param>
        /// <returns></returns>
        Model.Authors GetItem(SqlDataReader reader);

}

思考一下上面的代码，如果我有四个不同的类，每个类都有增删改查的方法，四个不同的类可不可以从接口继承来呢？作案是否定的，因为接口里面定义的方法返回的都是特定类型的值。那如果改成下面的泛型接口呢？

   public interface IDALConll<T>
    {
       /// <summary>
       /// 返回一个项集合
       /// </summary>
       /// <param name="sql"></param>
       /// <returns></returns>
       IList<T> GetItemConll(String sql);

       /// <summary>
       /// 返回一个单项
       /// </summary>
       /// <param name="reader"></param>
       /// <returns></returns>
       T GetItem(SqlDataReader reader);
       //以下是四个对数据库基本操作的方法
       T InsertInfo(T obj);
       T InsertInfo(T obj);
       T InsertInfo(T obj);
       T InsertInfo(T obj);
    }

从这里面大家应该看到了不同的东西，扩展性呢？当然是更上一层楼，其实这里的每个方法的返回值为 T，只是为了一个展示，完全可以按照不同的需求改，但是方法里面的参数就不同了，代码简洁及可实现正是从此而来，子类在实现接口中的方法时，方法里的参数类型可改成实现类型；即：DAL.Authors:IDALConll<Model.Authors>

其中Model.Authors 是实体类，

方法可写成public Model.Authors InsertInfo(Model.Authors authors){};

从这短短两行代码中，我们看到，这相当于子类继承抽象类的方法重写，是的，是相当于重写，但是比重写更灵活，重写的方法体里的参数不能改变，但是在这里却可以做到!