三层抽象工厂模式.docx

/389148/102304/jingyun/archive/2010/04/16/1713341.html实现步骤过程 1、创建Model，实现业务实体。2、创建IDAL，实现接口。3、创建SQLServerDAL，实现接口里的方法。4、增加web.config里的配置信息，为SQLServerDAL的程序集。5、创建DALFactory，返回程序集的指定类的实例。6、创建BLL，调用DALFactory，得到程序集指定类的实例，完成数据操作方法。7、创建WEB，调用BLL里的数据操作方法。 注意： 1、web.config里的程序集名称必须与SQLServerDAL里的输出程序集名称一致。2、DALFactory里只需要一个DataAccess类，可以完成创建所有的程序集实例。3、项目创建后，注意修改各项目的默认命名空间和程序集名称。4、注意修改解决方案里的项目依赖。5、注意在解决方案里增加各项目引用。 三、各层间的访问过程 1、传入值，将值进行类型转换(为整型)。2、创建BLL层的content.cs对象c，通过对象c访问BLL层的方法GetContentInfo(ID)调用BLL层。3、BLL层方法GetContentInfo(ID)中取得数据访问层SQLServerDAL的实例,实例化IDAL层的接口对象dal，这个对象是由工厂层DALFactory创建的，然后返回IDAL层传入值所查找的内容的方法dal.GetContentInfo(id)。4、数据工厂通过web.config配置文件中给定的webdal字串访问SQLServerDAL层，返回一个完整的调用SQLServerDAL层的路径给 BLL层5、到此要调用SQLServerDAL层，SQLServerDAL层完成赋值Model层的对象值为空，给定一个参数，调用SQLServerDAL层的SqlHelper的ExecuteReader方法,读出每个字段的数据赋值给以定义为空的Model层的对象。6、SqlHelper执行sql命令，返回一个指定连接的数据库记录集，在这里需要引用参数类型，提供为打开连接命令执行做好准备PrepareCommand。7、返回Model层把查询得到的一行记录值赋值给SQLServerDAL层的引入的Model层的对象ci，然后把这个对象返回给BLL。8、回到Web层的BLL层的方法调用,把得到的对象值赋值给Lable标签，在前台显示给界面.NET设计模式(1): 简单工厂模式简单工厂模式（Simple Factory Pattern）介绍：简单工厂模式不能说是一个设计模式，说它是一种编程习惯可能更恰当些。因为它至少不是Gof23种设计模式之一。但它在实际的编程中经常被用到，而且思想也非常简单，可以说是工厂方法模式的一个引导，所以我想有必要把它作为第一个讲一下。引入：我们在编程的时候，每当new一个对象之后，这个对象就依赖于这个类了。如果在后期的维护过程中由于某些原因需要修改一下这个类，则唯一的做法就是打开源代码，进行修改，修改所有与这个对象有关的操作。这对我们是非常不利的。问题出来了：对象不能应对“具体实例化类型”的变化解决思路：套用一下李建忠李老师的话，封装变化点，哪里变化，封装哪里。在这个例子中，要实例化的类变了，就将实例化这个操作封装起来，我们可以把new这个操作移交一个具体的类，由它去负责根据我们的条件创建具体类的实例，也就是下面要说的“简单工厂模式”。定义：专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类或接口。简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。意图：提供一个类，由它负责根据一定的条件创建某一具体类的实例参与者： 工厂角色（Creator）是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。 抽象产品角色（Product）是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。 具体产品角色（Concrete Product）继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。UML图：现实生活中例子：每次参加不同的聚会或者与不同的人见面，可能穿的衣服是不一样的，比如，你今天上午要与你的一个新客户见面，你可能会对你的老婆说：老婆，给拿件商务装（参数），我要去见我的一个客户，你老婆（工厂类）接到你的请求（商务装参数）后，从衣柜中取出一件商务装（具体产品），交给你。整个过程就完成了。分析：你可能根据不同的条件，要的衣服是不一样的，但要的衣服都是已经在你的衣柜中存在的。并且，每件上衣它们都属于同一种抽象，即它们可以从一个抽象类或接口中继承，这此衣服各自都有一定特征，这些都是条件。然后你要的时候，就可以向你老婆说一种特征，她就会根据这个特征为你服务了。这就是典型的简单工厂模式的应用。抽象产品类代码1/2/抽象产品类:上衣3/4publicinterfaceICoat56voidGetYourCoat();7非常简单，是吧？这里我只是举一个仅仅能说明问题的例子，在具体的项目中，可能是很复杂的哦。具体产品类代码1namespaceSimpleFactory23/4/具体产品类：商务上衣5/6publicclassBusinessCoat:ICoat78publicvoidGetYourCoat()910Console.WriteLine(商务上衣);11121314/15/具体产品类：时尚上衣16/17publicclassFashionCoat:ICoat1819/20/实现ICoat中定义的方法21/22/23publicvoidGetYourCoat()2425Console.WriteLine(时尚上衣);262728简单工厂模式中最核心的部分：工厂类1namespaceSimpleFactory23/4/简单工厂模式中的核心部分:工厂类5/6publicclassFactory78publicICoatCreateCoat(stringstyleName)910switch(styleName.Trim().ToLower()1112casebusiness:13returnnewBusinessCoat();14casefashion:15returnnewFashionCoat();16default:17thrownewException(还没有你要的那种衣服);18192021再看一下客户在调用的时候的代码1/2/客户类3/4classClient56staticvoidMain(stringargs)78ICoatfood;9try1011Factoryfactory=newFactory();1213Console.Write(我要的是时尚上衣t);14food=factory.CreateCoat(fashion);15food.GetYourCoat();161718catch(Exceptionex)1920Console.WriteLine(ex.Message);212223到这里，代码就完成了。在客户端的代码中有我们就可以根据具体的参数，返回我们希望返回的对象，将new操作推迟到工厂类中实现。这里，参数我直接写上了，我们其实可以将这个参数写到一个xml文件中，如app.config文件中，动态的读出来，需要穿另外一种衣服了，只需要打开app.config文件，修改里面的值就行了，不需要项目重新编译。这样这个小程序就能够适应一定的变化了（在上传上去的代码中我会修改一下）。其实它也是设计模式正要解决的问题，在不修改代码的情况下，使项目能够适应一定的客户需求变化。注意，是一定的，并非全部。优点： 简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。通过它，外界可以从直接创建具体产品对 象的尴尬局面中摆脱出来。 外界与具体类隔离开来，偶合性低。 明确区分了各自的职责和权力，有利于整个软件体系结构的优化。缺点： 工厂类集中了所有实例的创建逻辑，容易违反GRASPR的高内聚的责任分配原则 虽然简单工厂模式能够适应一定的变化，但是它所能解决