终极版:由简单工厂模式,升级到抽象工厂模式(用到反射)

前面两个已经学习简单三层到简单工厂模式的变化,但是简单工厂模式还是有个缺点,就是简单工厂中集合了所有的实例的创建。也不是很好。

现在想到使用抽象工厂的方式来实现这个:

我们在程序集中加上下面的代码:

<appSettings>
  <!--命名空间-->
  <add key="DALNameSpace" value="DAL"/>
  <!--程序集-->
  <add key="DALAssembly" value="DAL"/>
</appSettings>

然后新建一个抽象工厂类:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Reflection;
using System.Configuration;
using IDAL;
namespace DALFactory
{
   public class DALAbstractFactory
    {
       /// <summary>
       ///命名空间
       /// </summary>
       public static string DALNameSpace
       {
           get
           {
               return ConfigurationManager.AppSettings["DALNameSpace"];
           }
       }

       /// <summary>
       /// 程序集
       /// </summary>
       public static string DALAssembly
       {
           get
           {
               return ConfigurationManager.AppSettings["DALAssembly"];
           }
       }

       public IClassDAL GetClassInstance()
       {
           string fullNameSpace = DALNameSpace + ".ClassDAL";

          return CreateInstance(fullNameSpace, DALAssembly) as IDAL.IClassDAL;
       }

       /// <summary>
       /// 创建实例
       /// </summary>
       /// <param name="fullClassNameSpace"></param>
       /// <param name="assembly"></param>
       public static object CreateInstance(string fullClassNameSpace,string assembly)
       {
          var DALAssembly=  Assembly.Load(assembly);

         return DALAssembly.CreateInstance(fullClassNameSpace);
       }

    }
}

上面的方法,通过反射,创建DAL数据访问层的实例。

现在在业务层,我们可以这样:

using DAL;
using Entity;
using IDAL;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace BLL
{
    public class ClassBLL
    {
        //耦合度太高
       // ClassDAL dal = new ClassDAL();

        //这种还是有耦合,业务层和数据访问层耦合度太高

       //IClassDAL dal = new ClassDAL();

        //引入简单工厂模式

        //IClassDAL dal = DALFactory.DALFactory.GetClassInstance();

        //引入抽象工厂
        IClassDAL dal = DALFactory.DALAbstractFactory.GetClassInstance();

        /// <summary>
        /// 获取Class列表
        /// </summary>
        /// <returns></returns>
        public List<ClassEntity> GetList()
        {
            return dal.GetList();
        }
    }
}

效果图:

时间: 2024-10-22 05:37:04

终极版:由简单工厂模式,升级到抽象工厂模式(用到反射)的相关文章

设计模式之创建型模式—— 1.3 抽象工厂模式

<?php /**  * 1.3 抽象工厂模式  * 解决的问题:  *  如何解决多个类实例化对象的问题.  * 解决的方案:  *  提供一个创建一系列相关或相互依赖对象的  *    接口,而无需指定它们具体的类.  * 该模式包含四种角色:  *  1. 抽象产品角色(两个或多个)  *  职责:同工厂方法模式  *    2. 具体产品角色  *    职责:同工厂方法模式  *      3. 抽象工厂角色  *    职责:同工厂方法模式  *      4. 具体工厂角色  * 

工厂模式三部曲:抽象工厂模式

工厂模式三部曲:简单工厂模式 工厂模式三部曲:工厂方法模式 前言 这是工厂模式三部曲中的最后一篇了,在这篇文章中将会讲述抽象工厂模式,抽象工厂模式正如其名字一样,非常抽象.但是抽象工厂模式的功能却十分强大,对抽象工厂的利用也非常好. 这篇文章中会像本系列第一篇一样,给出普通实现方式和使用了反射机制的实现两种代码,并且会说明这两种实现方式的区别.并且在文章的最后,会将这三种模式放在一起,对这三种工厂模式进行总结. 本人理解可能不够深刻,这一系列文章中存在的问题,欢迎大家提出,谢谢! 什么是抽象工厂

浅析设计模式(六)——创建型模式之Abstract-Factory(抽象工厂模式)

抽象工厂模式Abstract-Factory 本文的套路: 抽象工厂模式的定义 抽象工厂模式的参与者及其角色 抽象工厂模式的类图 抽象工厂模式的示例 参考 抽象工厂模式的定义 提供一个接口,用于创建相关或依赖对象的家族,而不需要明确指定具体类. 前面[浅析设计模式(四)--创建型模式之Simple-Factory(简单工厂方法,非设计模式)]中介绍的简单工厂方法,虽然已经对变化的部分进行了封装,但是这里只由一个对象负责所有的具体类的实例化,因此每次有新增对象类型时,都需要改变工厂的源码进行扩展.

简单理解C#中的抽象工厂模式是什么概念!

抽象工厂模式向客户端提供一个接口,使得客户端在不必指定具体类型的情况下,创建多个产品族中的对象.本文采取的仍然是接着以前的那个快餐店的例子.现在,快餐店经常良好,逐渐发展壮大,为了适合不同地方人的饮食习惯,创建了两大系列(相当于产品族)快餐,北方系列和南方系列.每个系列分别由一个大厨掌勺.抽象工厂模式对新的产品族支持开闭原则,但对新的产品不支持开闭原则.例如增加新的产品族,如增加美国系列快餐(相当于增加了一个产品族),则只要从每个产品接口继承一个相应美国系列产品即可,不需要更改已有的代码.但如果

《JAVA与模式》之抽象工厂模式

场景问题 举个生活中常见的例子--组装电脑,我们在组装电脑的时候,通常需要选择一系列的配件,比如CPU.硬盘.内存.主板.电源.机箱等.为讨论使用简单点,只考虑选择CPU和主板的问题. 事实上,在选择CPU的时候,面临一系列的问题,比如品牌.型号.针脚数目.主频等问题,只有把这些问题都确定下来,才能确定具体的CPU. 同样,在选择主板的时候,也有一系列问题,比如品牌.芯片组.集成芯片.总线频率等问题,也只有这些都确定了,才能确定具体的主板. 选择不同的CPU和主板,是每个客户在组装电脑的时候,向

(创建型模式三)抽象工厂模式

package com.eyugame.modle; /** * 抽象工厂模式 * * @author JYC506 * */ public class MyFactory implements IAbstractFactory { @Override public IProduct1 createIProduct1() { return new Product1(); } @Override public IProduct2 createIProduct2() { return new Pro

工厂模式三部曲之抽象工厂模式

工厂方法模式有一个问题就是,类的创建依赖工厂类,也就是说,如果想要拓展程序,必须对工厂类进行修改,这违背了闭包原则,所以,从设计角度考虑,有一定的问题,如何解决?就用到抽象工厂模式,创建多个工厂类,这样一旦需要增加新的功能,直接增加新的工厂类就可以了,不需要修改之前的代码.因为抽象工厂不太好理解,我们先看看图,然后就和代码,就比较容易理解. 举例如下:(我们举一个发送邮件和短信的例子) public interface Sender { public void Send(); } 两个实现类:

设计者模式详解--抽象工厂模式

1. 概述 抽象工厂模式为一个产品家族提供了统一的创建接口.当需要这个产品家族的某一系列的时候,可以从抽象工厂中选出相对应的系列来创建一个具体的工厂类别. 2. 抽象工厂模式中的角色 2.1 抽象工厂(AbstractFactory):担任这个角色的是工厂方法模式的核心,它是与应用系统商业逻辑无关的. 2.2 具体工厂(ConcreteFactory):这个角色直接在客户端的调用下创建产品的实例.这个角色含有选择合适的产品对象的逻辑,而这个逻辑是与应用系统的商业逻辑紧密相关的. 2.3 抽象产品

抽象模式之【抽象工厂模式】

原则:依赖倒转原则:针对接口编程,依赖于抽象而不依赖于具体: 一.创建接口:发送消息 package Factory; public interface Sender{ public void Send(); } 二.创建两个实现类 1.发送邮箱 package Factory; public class MailSend implements Sender{ @Override public void Send() { System.out.println("mailsend");