.net分层架构思想(彻底分离每个层)

简介:

提到分层,我就想起一句图灵奖获得者说过的话:计算机科学领域任何问题,都可以间接的通过添加一个中间层来解决;当初看到这句话的时候还不能深刻的体会到这句话的真正灵魂是什么。之所以要写这篇文章作为技术爱好者之一更愿意与大家分享技术给我们带来的快乐,本人将从另一个角度来解析.NET分层架构的真正奥秘。分层,一些技术功底比较薄弱的程序员听到分层就会联想到三层架构(BLL,DAL之类的),其实不是,分层是一个很大的技术框架思想,三层架构只不过是对普通的信息系统来说,将信息的流转通过三层来分解,在开发系统时一般总会在解决方案中新建一个Model层、一个BLL层、然后DAL层;其实如果是这样建项目的话跟一个解决方案中放上一个程序一样的只不过可以用文件夹分开建立文件是一回事;技术水品的不同对三层的理解各不相同,有时会加上一个接口层让每层依赖接口来实现,像上面的BLL、DAL之类的架构,只是人为的分解感觉解决方案看上去很清晰一幕了然,对框架来说没有什么分离作用,还是高耦合低类聚;

在分层架构中,是从总体上对系统进行一个分层,里面涉及纵横向的概念,一个大的系统从业务逻辑来讲可以不是单单的对信息的处理,也可能涉及到对一些其他的逻辑处理,这里就不能单单的把逻辑抽象到三层中,三层是横向分层中的一个层,如果对分层的焦距拉远点看是看不到三层的,如果把焦距拉近点看也许目标不会锁定在信息流的处理子层中,说起来比较抽象来个图吧;

 

上图中将一个大的系统分解为三个业务逻辑块其实也就是我所说的三个大的层面,我们将焦距拉近看业务逻辑1中的子层;

 

逻辑1这个大层被分解为两个子层BLL、和DAL,也就是我们常用的业务逻辑层和数据访问层;业务逻辑1层中主要是用来对数据库的增、删、改、查操作,将其抽象成BLL和DAL也是我们所熟悉的三层;在另外两个业务逻辑层中一样可以将其分解层多道子层;将子层分开后就要涉及到具体实现的问题了,就拿C#面向对象语言来将,架构跟思想都是一些方法论的东西,具体实现是少不了的;层是分好了是否在开发过程中真真做到层层隔离,不互相依赖,所以是用接口层分割开来,将具体的实现层脱离开来,我们将BLL层改为BLL接口层BLLI,将DAL层改为DAL接口层DALI,这样让BLL、DAL去实现BLLI和DALI接口,完全分离开发,这也是面向对象所提倡的面向接口编程而不是面向实现编程;

 

以后BLL层出现问题可以完全替换掉换另一个BLL层,DAL层同样也一样;但是这是思想性的东西落实到代码还没那么简单:

如:BLLI B=new BLL();//在通常情况下是这样去用接口的,但是似乎没有理论说的那么干净的分离,我们在通过添加一个工厂来实现分离;

 

这样在使用时:BLLI B=new BLLI工厂(BLLI接口类型);在调用工厂的时候将接口的类型做为参数传进去,在工厂中在通过接口类型去查找具体的实现对象;如:

        public static T GetInterfaceRealization<T>(Type interfacetype)
        {

            Assembly ass = Assembly.LoadFrom("程序集的名称");

            Type[] asstype = ass.GetTypes();
            if (asstype.Length <= 0)
                throw new Exception("接口管理器的异常:该程序集没有任何实现类");
            for (int i = 0; i < asstype.Length; i++)
            {
                //获取该实现类的整个继承链中是否有传入的接口类型;
                Type oddinterfacetype = asstype[i].GetInterface(interfacetype.Name);
                if (oddinterfacetype != null)
                {
                    T t = (T)System.Activator.CreateInstance(asstype[i]);
                    return t;//返回动态实例化的接口实现类;
                }
            }
            throw new Exception("接口管理器的异常:没有该接口的实现类,必须先实现接口类才能查找");
        }

 因为同一个解决方案中的不同项目彼此直接引用时,有利于项目的开发调试,但是我们的BLL和调用方是完全没有任何依赖的在程序调用时候没有任何类型的调用所以在解决方案生成的时候不会将我们引用的项目程序集拷贝到执行目录中,如果想省略手工操作可以在执行查找的时候先调用一下实现层的对象,这样当编译生成的时候代码检查到你有调用会将你调用的项目程序集拷贝到执行目录中,在通过接口工厂动态查找时不会失败;

这样就彻底的实现层层分离的规则;所谓思考是前进的本质,本人也是通过不断的思考总结出来的一点点小的经验与大家分享一下,如果有什么地方说的不对的地方请大家指出,谢谢;


本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/wangqingpei557/archive/2011/02/26/6209901.aspx




 本文转自 王清培 51CTO博客,原文链接:http://blog.51cto.com/wangqingpei557/525152,如需转载请自行联系原作者

相关文章
|
10月前
|
存储 数据挖掘 BI
2-5 倍性能提升,30% 成本降低,阿里云 SelectDB 存算分离架构助力波司登集团实现降本增效
波司登集团升级大数据架构,采用阿里云数据库 SelectDB 版,实现资源隔离与弹性扩缩容,查询性能提升 2-5 倍,总体成本降低 30% 以上,效率提升 30%,助力销售旺季高效运营。
598 9
|
8月前
|
存储 SQL 消息中间件
从 ClickHouse 到 StarRocks 存算分离: 携程 UBT 架构升级实践
查询性能实现从秒级到毫秒级的跨越式提升
|
8月前
|
人工智能 API 数据库
Semantic Kernel .NET 架构学习指南
本指南系统解析微软Semantic Kernel .NET架构,涵盖核心组件、设计模式与源码结构,结合实战路径与调试技巧,助你从入门到贡献开源,掌握AI编排开发全栈技能。
940 2
|
存储 运维 Serverless
千万级数据秒级响应!碧桂园基于 EMR Serverless StarRocks 升级存算分离架构实践
碧桂园服务通过引入 EMR Serverless StarRocks 存算分离架构,解决了海量数据处理中的资源利用率低、并发能力不足等问题,显著降低了硬件和运维成本。实时查询性能提升8倍,查询出错率减少30倍,集群数据 SLA 达99.99%。此次技术升级不仅优化了用户体验,还结合AI打造了“一看”和“—问”智能场景助力精准决策与风险预测。
1270 69
|
资源调度 前端开发 算法
鸿蒙OS架构设计探秘:从分层设计到多端部署
本文深入探讨了鸿蒙OS的架构设计,从独特的“1+8+N”分层架构到模块化设计,再到智慧分发和多端部署能力。分层架构让系统更灵活,模块化设计通过Ability机制实现跨设备一致性,智慧分发优化资源调度,多端部署提升开发效率。作者结合实际代码示例,分享了开发中的实践经验,并指出生态建设是未来的关键挑战。作为国产操作系统的代表,鸿蒙的发展值得每一位开发者关注与支持。
|
人工智能 前端开发 JavaScript
前端架构思考 :专注于多框架的并存可能并不是唯一的方向 — 探讨大模型时代前端的分层式微前端架构
随着前端技术的发展,微前端架构成为应对复杂大型应用的流行方案,允许多个团队使用不同技术栈并将其模块化集成。然而,这种设计在高交互性需求的应用中存在局限,如音视频处理、AI集成等。本文探讨了传统微前端架构的不足,并提出了一种新的分层式微前端架构,通过展示层与业务层的分离及基于功能的横向拆分,以更好地适应现代前端需求。
642 0
|
开发框架 前端开发 .NET
一个适用于 .NET 的开源整洁架构项目模板
一个适用于 .NET 的开源整洁架构项目模板
360 26
|
数据库
分层架构
表现层(Presentation Layer):处理用户界面和用户交互逻辑。 业务逻辑层(Business Logic Layer):处理业务相关的逻辑和规则。 数据访问层(Data Access Layer):负责与数据库或其他数据源进行 [Something went wrong, please try again later.]。