根据业务自己设计的.NET工厂模式架构

最近项目的架构需要做调整优化,根据业务需要写了一个简单的工厂模式架构

项目介绍:整个系统分为三大平台(这里用A,B,C来标示),每个平台又细分为多个APP客户端(每个APP都有appid来区分)

因为每个平台的业务处理几乎不一样,而属于同一个平台的app客户端业务又几乎一样,但也有要特殊情况处理的。

直接代码展示:

首先是接口和抽象类

    /// <summary>
    /// 商品接口类
    /// </summary>
    public interface IProductBLL
    {
        string GetBLLName(int appid);

        string GetAction();
    }

    /// <summary>
    /// 抽象类
    /// </summary>
    public abstract class BaseProductBLL : IProductBLL
    {

        public static IProductBLL GetProductBll(int appid)
        {
            //定义appid属于哪个平台,这里可以用config配置或者枚举定义
            int[] A_appid = new int[] {10001,10003,10005 };
            int[] B_appid = new int[] { 10002, 10004, 10006 };
            int[] C_appid = new int[] { 10007, 10008, 100009 };
            IProductBLL bll = null;

            if (A_appid.Contains(appid))//此appid属于A平台
            {
                bll = BaseProduct_A_BLL.GetProductBll(appid);
            }
            else if (B_appid.Contains(appid))//此appid属于B平台
            {
                bll = BaseProduct_B_BLL.GetProductBll(appid);
            }
            else if (C_appid.Contains(appid))//此appid属于C平台
            {
                bll = BaseProduct_C_BLL.GetProductBll(appid);
            }

            return bll;
        }

        public abstract string GetBLLName(int appid);
        public abstract string GetAction();
    }

接下来是各平台的通用类

    /// <summary>
    /// A平台通用类
    /// </summary>
    public class BaseProduct_A_BLL : BaseProductBLL
    {
        private static IProductBLL _instanceA = null;
        public static IProductBLL InstanceA
        {
            get
            {
                if (_instanceA == null)
                {

                    _instanceA = new BaseProduct_A_BLL();
                }
                return _instanceA;
            }
        }
        public static IProductBLL GetProductBll(int appid)
        {
            IProductBLL bll = null;

            switch (appid)
            {
                case 10003:
                    bll=Product_10003_BLL.Instance10003;
                    break;
                default:
                    bll = BaseProduct_A_BLL.InstanceA;
                    break;
            }

            return bll;
        }

        public override string GetBLLName(int appid)
        {
            return "" + appid + "调用了BaseProduct_A_BLL.GetBLLName";
        }

        public override string GetAction()
        {
            return "调用了BaseProduct_A_BLL.GetAction";
        }

    }

    /// <summary>
    /// B平台通用类
    /// </summary>
    public class BaseProduct_B_BLL : BaseProductBLL
    {
        private static IProductBLL _instanceB = null;
        public static IProductBLL InstanceB
        {
            get
            {
                if (_instanceB == null)
                {

                    _instanceB = new BaseProduct_B_BLL();
                }
                return _instanceB;
            }
        }
        public static IProductBLL GetProductBll(int appid)
        {
            IProductBLL bll = null;

            switch (appid)
            {
                default:
                    bll = BaseProduct_B_BLL.InstanceB;
                    break;
            }

            return bll;
        }

        public override string GetBLLName(int appid)
        {
            return "" + appid + "调用了BaseProduct_B_BLL.GetBLLName";
        }

        public override string GetAction()
        {
            return "调用了BaseProduct_B_BLL.GetAction";
        }

    }

    /// <summary>
    /// C平台通用类
    /// </summary>
    public class BaseProduct_C_BLL : BaseProductBLL
    {
        private static IProductBLL _instanceC = null;
        public static IProductBLL InstanceC
        {
            get
            {
                if (_instanceC == null)
                {

                    _instanceC = new BaseProduct_C_BLL();
                }
                return _instanceC;
            }
        }
        public static IProductBLL GetProductBll(int appid)
        {
            IProductBLL bll = null;

            switch (appid)
            {
                default:
                    bll = BaseProduct_C_BLL.InstanceC;
                    break;
            }

            return bll;
        }

        public override string GetBLLName(int appid)
        {
            return "" + appid + "调用了BaseProduct_C_BLL.GetBLLName";
        }

        public override string GetAction()
        {
            return "调用了BaseProduct_C_BLL.GetAction";
        }
    }

假如appid为10003的需要拓展,需在A平台通用类中添加case 10003 的逻辑,并创建对应的拓展类Product_10003_BLL并继承A平台通用类BaseProduct_A_BLL

    /// <summary>
    /// appid为10003拓展类
    /// </summary>
    public class Product_10003_BLL : BaseProduct_A_BLL
    {
        private static IProductBLL _instance10003 = null;
        public static IProductBLL Instance10003
        {
            get
            {
                if (_instance10003 == null)
                {

                    _instance10003 = new Product_10003_BLL();
                }
                return _instance10003;
            }
        }

        public Product_10003_BLL()
        {
        }

        public override string GetBLLName(int appid)
        {
            return "" + appid + "调用了Product_10003_BLL.GetBLLName";
        }
    }

如上appid为10003的拓展类重写了GetBLLName方法。

接下来就是在Controlle层中调用

    /// <summary>
    /// 基类控制类
    /// </summary>
    public class BasesController : Controller
    {
        public BasesController()
        {
        }

        protected int Appid
        {
            get { return Convert.ToInt32(HttpContext.Request["appid"]); }
        }

        public IProductBLL ProductBll
        {
            get
            {
                return BaseProductBLL.GetProductBll(Appid);
            }
        }
    }

    public class ProductController : BasesController
    {
        //
        // GET: /Product/
        public ActionResult Index()
        {
            string bllname = ProductBll.GetBLLName(Appid);
            string actionName = ProductBll.GetAction();
            ViewData["bllname"] = bllname;
            ViewData["actionName"] = actionName;
            return View();
        }

    }

以上参数appid是必传,以上代码没有对不传参数且参数值得正确性做判断的异常处理,这里主要是记录对于这个系统的交互设计,另外数据访问层DAL也没有写出来,可以按照上面的设计思路进行创建

下面是我简单测试打印出来的

ViewData["bllname"] 
ViewData["actionName"] 的值

访问http://localhost:37842/product/index?appid=10005

也就是参数appid为10005 时打印出 :

10005调用了BaseProduct_A_BLL.GetBLLName

调用了BaseProduct_A_BLL.GetAction

当appid为10003时打印出:

10003调用了Product_10003_BLL.GetBLLName

调用了BaseProduct_A_BLL.GetAction

当appid为10002时打印出:

10002调用了BaseProduct_B_BLL.GetBLLName

调用了BaseProduct_B_BLL.GetAction

此文仅记录笔记,各位大神可以多多指教!

时间: 2025-01-03 22:02:20

根据业务自己设计的.NET工厂模式架构的相关文章

C#面向对象设计之——抽象工厂模式(四)

一.前言 工厂方法模式是为了克服简单工厂模式的缺点而设计出来的,简单工厂模式的工厂类随着产品类的增加需要增加额外的代码),而工厂方法模式每个具体工厂类只完成单个实例的创建,所以它具有很好的可扩展性.但是在现实生活中,一个工厂只创建单个产品这样的例子很少,因为现在的工厂都多元化了,一个工厂创建一系列的产品,如果我们要设计这样的系统时,工厂方法模式显然在这里不适用,然后抽象工厂模式却可以很好地解决一系列产品创建的问题. 抽象工厂模式提供创建一系列相关或者相互依赖对象的接口. 二.结构图 三.实例代码

pyhon面向对象设计之抽象工厂模式

简介 抽象工厂设计模式属于创建型设计模式的一种,创建型设计模式更关注对象是如何被创建出来的.通常我们会调用对象的构造函数来创建对象实例,比如通过向类名称传递相关参数来创建.但是,有时候我们会需要更加灵活的对象创建方式,这时创建型的设计模式就会大有用处了.今天我们主要关注创建型的设计模式中的抽象工厂设计模式.抽象工厂设计模式主要用于对于某一个系统而言,根据配置文件的不同或者系统平台(windows/mac/linux)的不同有多种不同的实现方式的时候.比如:在一个GUI系统里,我们可能有一个抽象的

C#面向对象设计之——简单工厂模式(二)

一.前言 简单工厂是一个负责生产对象的中间类,例如有加减乘除四个运算方法,它们继承父类,并重写父类的方法,简单工厂根据不同的运算符创建不同的实例对象赋值给父类,实现了面向对象的另一个原则——降低对象之间的耦合度.简单工厂模式解决了客户端直接依赖于具体对象的问题,客户端可以消除直接创建对象的责任,而仅仅是消费产品.简单工厂模式实现了对责任的分割. 简单工厂模式的缺点: 工厂类集中了所有产品创建逻辑,一旦不能正常工作,整个系统都会受到影响 系统扩展困难,一旦添加新产品就不得不修改工厂逻辑,这样就会造

java设计模型 解析工厂模式、proxy-agent模式、templete模式

1.Factory Design pattern 工厂设计模式的优点 (1)工厂设计模式提供了接口而不是实现的代码方法. (2)工厂模式从客户端代码中删除实际实现类的实例化.工厂模式使我们的代码更健壮,耦合更少,易于扩展.例如,我们可以轻松更改PC类实现,因为客户端程序不知道这一点. (3)工厂模式通过继承提供实现和客户端类之间的抽象. JDK中工厂设计模式实列 java.util.Calendar,ResourceBundle和NumberFormat getInstance()方法使用Fac

GOF业务场景的设计模式-----工厂模式

定义:定义一个用于创建对象的接口,让子类决定实例化哪一个类,工厂方法使一个类的实例化延迟到其子类. 工厂方法模式 基本代码 interface IProduct { public void productMethod(); } class Product implements IProduct { public void productMethod() { System.out.println("产品"); } } interface IFactory { public IProduc

从接口、抽象类到工厂模式再到JVM来总结一些问题

俗话说,自己写的代码,6个月后也是别人的代码……复习!复习!复习! 涉及到的知识点总结如下: 为什么使用接口? 接口和抽象类的区别 简单工厂模式总结 Java中new和newInstance的区别 Java的Class.forName(xxx); Java里创建对象的几个方式总结 Java类加载机制总结 Java WEB的三层架构和MVC的关系 工厂方法模式总结 抽象工厂模式总结 一道面试题的分析 一个服务提供者框架的学习 接口的另一常用法:策略模式 参考资料 先看这样一个场景:某个果园里现在有

.NET设计模式(3):抽象工厂模式(Abstract Factory)(转)

概述 在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作:同时由于需求的变化,往往存在着更多系列对象的创建工作.如何应对这种变化?如何绕过常规的对象的创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?这就是我们要说的抽象工厂模式. 意图 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类. 模型图 逻辑模型: 物理模型: 生活中的例子 抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口,而不需要指定它们具体的类.这种

.NET设计模式(3):抽象工厂模式(Abstract Factory)

抽象工厂模式(Abstract Factory) ——探索设计模式系列之三 Terrylee,2005年12月12日 概述 在软件系统中,经常面临着“一系列相互依赖的对象”的创建工作:同时由于需求的变化,往往存在着更多系列对象的创建工作.如何应对这种变化?如何绕过常规的对象的创建方法(new),提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合?这就是我们要说的抽象工厂模式. 意图 提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类. 模型图 逻辑模型:

漫谈设计模式之工厂模式

今天在这里不过多介绍什么是设计模式和为什么要使用它?可以参考漫谈设计模式之组合模式. 一.什么是抽象工厂设计模式? 一言以蔽之,抽象工厂就是用来创建功能相关的类, 二.在什么场景下使用它? 顾名思义,在我们的业务当中会有一种场景,有一个查询页面,上面有很多很多的查询条件,最终你会组合这些查询条件查询出实际想要的数据,请问你是怎么做的?下面是我的设计,运用了单例.工厂和策略模式,一切面向接口编程. 三.设计思路 1.定义策略接口,定义一个format方法 2.按实际业务抽象出三种策略,1.模糊查询