一个分层架构设计的例子(2)

简介:
接着上一篇关于分层架构的讨论, 一个分层架构设计的例子(1)
上篇介绍了实体类(Entity)、数据库访问类(DAL)、数据访问接口(IDAL)的相关设计,本篇主要讨论下面几个部分内容:业务逻辑层、缓存机制、界面层等方面。
业务逻辑层,主要是业务逻辑基类的设计,由于数据库访问类(DAL)的基类封装了大量的操作实现,因此,业务逻辑层的主要工作是进一步封装对底层访问接口的实现,如下所示。
     public   class  BaseBLL < T >   where  T : BaseEntity,  new ()
    
{
        
构造函数

        
对象添加、修改、删除等接口

        
返回集合的接口
    }
业务层基类封装了大量的调用,那么对于业务层的具体操作类,它的工作就很简单了,基本上只需要继承一下基类就可以了,这就是有一个优秀父亲的好处,呵呵
     public   class  Equipment : BaseBLL < EquipmentInfo >
    
{
        
public Equipment() : base()
        
{
        }

    }
基本上,业务层的设计到此应该收尾了,可是我们注意到,很多开发都使用了缓存的机制来进一步提高程序的性能,下面对这方面进行讨论。缓存的机制,一般是把创建过的对象资源放到一个集合中,需要的时候,调出来,如下业务层的工厂类所示。
     public   class  BLLFactory < T >   where  T :  class
    
{
        
private static Hashtable objCache = new Hashtable();
        
public static T Instance
        
{
            
get
            
{
                
string CacheKey = typeof(T).FullName;
                T bll 
= (T)objCache[CacheKey];  //从缓存读取  
                if (bll == null)
                
{
                    bll 
= Reflect<T>.Create(typeof(T).Name, "HuaweiSoftware.IPSPBD.BLL"); //反射创建,并缓存
                }

                
return bll;
            }

        }

    }
  
这是一个业务逻辑类工厂创建类,我们在界面层只需要如下调用即可构造一个(利用了缓存)具体的业务类出来
CustomerInfo info  =  BLLFactory < Customer > .Instance.FindByID(ID);
在上面的BaseBLL和BLLFactory类中,有一个Reflect的操作类,这是反射缓存的具体实现所在,我们探讨一下它的实现。
     public   class  Reflect < T >   where  T :  class  
    
{
        
private static Hashtable m_objCache = null;
        
public static Hashtable ObjCache
        
{
            
get
            
{
                
if (m_objCache == null)
                
{
                    m_objCache 
= new Hashtable();
                }

                
return m_objCache;
            }

        }


        
public static T Create(string sName, string sFilePath)
        
{
            
return Create(sName, sFilePath, true);
        }

        
public static T Create(string sName, string sFilePath, bool bCache)
        
{
            
string CacheKey = sFilePath + "." + sName;
            T objType 
= null;
            
if (bCache)
            
{
                objType 
= (T)ObjCache[CacheKey];    //从缓存读取 
                if (!ObjCache.ContainsKey(CacheKey))
                
{
                    Assembly assObj 
= CreateAssembly(sFilePath);
                    
object obj = assObj.CreateInstance(CacheKey);
                    objType 
= (T)obj;

                    ObjCache.Add(CacheKey, objType);
// 写入缓存 将DAL内某个对象装入缓存
                }

            }

            
else
            
{
                objType 
= (T)CreateAssembly(sFilePath).CreateInstance(CacheKey); //反射创建 
            }


            
return objType;
        }


        
public static Assembly CreateAssembly(string sFilePath)
        
{
            Assembly assObj 
= (Assembly)ObjCache[sFilePath];
            
if (assObj == null)
            
{
                assObj 
= Assembly.Load(sFilePath);
                ObjCache.Add(sFilePath, assObj);
//将整个DLL装入缓存
            }

            
return assObj;
        }

    }
另外,如果你在业务层需要实现更加复杂的功能,而数据库访问基类BaseDAL提供的函数不能满足你的需要,可以扩展数据访问层的接口和实现,如下所示。
     public   interface  ICustomer : IBaseDAL < CustomerInfo >
    
{
        List
<string> GetAllCustomerNumber();

        CustomerInfo GetByCustomerNumber(
string number);
    }



    
public   class  Customer : BaseDAL < CustomerInfo > , ICustomer
    
{
        
对象实例及构造函数

        

        
ICustomer 成员
    }
那么在业务层的类修改如下
     public   class  Customer : BaseBLL < CustomerInfo >
    
{
        
public Customer() : base()
        
{
        }


        
public List<string> GetAllCustomerNumber()
        
{
            ICustomer customerDAL 
= baseDal as ICustomer;
            
return customerDAL.GetAllCustomerNumber();
        }


        
public CustomerInfo GetByCustomerNumber(string number)
        
{
            ICustomer customerDAL 
= baseDal as ICustomer;
            
return customerDAL.GetByCustomerNumber(number);
        }

    }
最后,界面方面的设计是见仁见智,但根本一条是利用一些控件,可以统一风格,减少劳动,给出几个界面的设计截图供大家参考
WinForm方面的(颜色标明的是使用了特定的界面控件,其中红色部分为和整个架构整合起来的分页控件,集成了一些基本的右键菜单操作,包括打印功能、数据导出功能等):
WinForm_UI1.jpg
Winform分页控件设计视图
GridViewPager.jpg
可以选择列进行打印
GridViewPager_PrintOption.jpg
在实际运用过程中的界面效果
GridViewPager_Product.jpg
WebForm方面的(可以使用之前文章介绍的查询控件、分页控件、内容编辑控件):
下图是查询控件和分页控件的一起运用:

WebForm_UI1.jpg
修改内容时候的编辑控件
WebForm_UI2.jpg
查看内容时候的编辑控件
WebForm_UI3.jpg

以上所引用的代码是通过代码生成工具Database2Sharp自动生成(http://www.iqidi.com/Database2Sharp.htm),选择EnterpriseLibrary架构即可。
Database2Sharp_Enterprise.jpg

本文转自博客园伍华聪的博客,原文链接:一个分层架构设计的例子(2),如需转载请自行联系原博主。



目录
相关文章
|
6月前
|
负载均衡 关系型数据库 应用服务中间件
高可用系列文章之二 - 传统分层架构技术方案
高可用系列文章之二 - 传统分层架构技术方案
|
8天前
|
人工智能 前端开发 JavaScript
前端架构思考 :专注于多框架的并存可能并不是唯一的方向 — 探讨大模型时代前端的分层式微前端架构
随着前端技术的发展,微前端架构成为应对复杂大型应用的流行方案,允许多个团队使用不同技术栈并将其模块化集成。然而,这种设计在高交互性需求的应用中存在局限,如音视频处理、AI集成等。本文探讨了传统微前端架构的不足,并提出了一种新的分层式微前端架构,通过展示层与业务层的分离及基于功能的横向拆分,以更好地适应现代前端需求。
|
22天前
|
JSON 前端开发 Java
Spring Boot框架中的响应与分层解耦架构
在Spring Boot框架中,响应与分层解耦架构是两个核心概念,它们共同促进了应用程序的高效性、可维护性和可扩展性。
42 3
|
27天前
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。
|
3月前
|
存储 消息中间件 JSON
|
4月前
|
运维 Java Docker
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
业务系统架构实践问题之在某些情况下,将能力代码和业务逻辑严格分层可能是一个挑战问题如何解决
|
4月前
|
存储 搜索推荐 API
业务系统架构实践问题之分层架构中的四层定位是什么
业务系统架构实践问题之分层架构中的四层定位是什么
102 0
|
4月前
|
缓存 项目管理
项目管理定义问题之DDD架构的分层架构中基础层作用是什么
项目管理定义问题之DDD架构的分层架构中基础层作用是什么
|
4月前
|
存储 消息中间件 Kafka
细说数据仓库分层架构
【7月更文挑战第20天】数据仓库分层架构包括缓冲层、操作数据层、明细数据层、汇总数据层和数据集市层。
|
4月前
|
前端开发 Java 关系型数据库
「架构」分层架构
**分层架构**是软件设计的关键模式,它将应用划分为独立层,如表示层、业务逻辑层和数据访问层,强调**单一职责**和**松耦合**。优点包括**代码组织**、**技术多样性**、**团队协作**和**可扩展性**,但可能带来**性能影响**和**设计复杂性**。通过定义清晰接口和合理划分层次来管理。常用技术栈涉及Web前端、后端框架、数据库、ORM和通信协议等。
71 0

热门文章

最新文章