C# N层架构和解耦

打印 上一主题 下一主题

主题 995|帖子 995|积分 2985

目次

一.N层头脑
  我们为什么要分层?
建议:
二、解耦 —— 什么是解耦?我们为什么要解耦?解耦能给我们带来什么?
1)什么是解耦
2)为什么要解耦
3)解耦能带来什么
总结:
三、我们为什么要采用多层架构?
总结:



一.N层头脑


  我们为什么要分层?

        为了解耦,高内聚,低耦合


  •   如大家熟知的三层架构&多层架构

                                                               (多层架构


   

  • Model:模子,主要负责数据库中对象(表,视图,存储过程等)的映射,将来在C#语言中利用Model就相当于利用了数据库中的对象。
  • IDAL:接口层,数据访问层接口,主要负责抽离DAL层公共的方法。
  • DAL:Data Access Layer数据访问层,主要负责和数据库的交互(增,删,查,改)。将来可以利用差别的数据库技术来实现(SQL Server, MySQL, Oracle等)
                  ——一样平常也分为两层,主要将DAL层中的共有利用抽象出来
  

  • BLL:Business Logic Layer业务逻辑层,主要负责对DAL封装;可以把UI的验证逻辑转移到BLL层;让UI层和DAL解耦。
                  ——这一层可以分为许多子层;
                ——事务的处理在BLL中进行;
  

  • 如果没有BLL层,UI层需要直接和DAL交互。我们为什么不让UI层和DAL直接交互?为了解耦,让DAL的实现更机动。
  • DALFactory:抽象工厂层,生产DAL的工厂,主要好处:让BLL和DAL解耦。
  • 工具包分层:(这一层不太告急)
    DBUtitlity:工具包,和数据访问的工具包。只在SQLServerDAL层利用了。
    Common:公共的工具包。这些工具包有大概在所有层被利用。
  建议:

        在开发过程中,由于SQLServerDAL层中的代码有大概不断的修改,如果频繁的拷贝很贫苦,建议在开发者中,UI层强引用SQLServerDAL,但UI层的代码中不应该利用SQLServerDAL层的任何对象,应该利用BLL层中的对象。项目开发完,移除SQLServerDAL,手动拷贝SQLServerDAL及它依靠的类库,放到UI层bin/debug

二、解耦 —— 什么是解耦?我们为什么要解耦?解耦能给我们带来什么?

1)什么是解耦

        解耦,即排除耦合,是一种在软件开发中广泛应用的设计理念和方法。耦合形貌的是软件系统中各个模块之间相互依靠、相互影响的水平。当模块之间的耦合度高时,意味着一个模块的修改或变更会对其他模块产生较大的影响;而解耦就是通过一系列的设计和技术手段,降低模块之间的这种依靠关系,使得各个模块能够相对独立地进行开发、测试、维护和扩展。
           比方,在一个电商系统中,原本订单处理模块和库存管理模块紧密耦合,订单处理时直接调用库存管理模块的方法来扣减库存。经过解耦后,订单处理模块不再直接依靠库存管理模块,而是通过消息队列等方式将订单信息通报给库存管理模块,这样两个模块的关联性就大大降低。
  (解耦解耦 “藕断丝连”  目的为了降低模块间依靠水平 克制出现牵一发动全身的状态出现,增加产品的可扩展性降低后期维护成本)
2)为什么要解耦



  • 适应需求变革:在软件开发过程中,用户的需求是不断变革的。如果系统模块之间耦合度高,当需求发生变革需要修改某个模块时,大概会波及到其他多个模块,甚至大概引发一系列难以预料的标题。而解耦后的系统,各个模块相对独立,修改某个模块时对其他模块的影响较小,能够更机动地应对需求的变革。
   (比方,如果业务逻辑层出现了一个 bug,由于它与其他层是解耦的,开发职员可以专注于业务逻辑层的代码进行调试和修复,而不必担心会影响到其他层的功能)
  

  • 提高可维护性:高耦合的系统中,代码的关联性复杂,维护职员在修改代码时需要耗费大量的时间去理解各个模块之间的依靠关系,容易引入新的错误。解耦后,每个模块的功能和职责更加清晰,维护职员可以专注于单个模块的代码,降低维护的难度和成本
  • 便于团队协作:在大型软件开发项目中,通常会有多个开发团队或开发职员分别负责差别的模块。如果模块之间耦合度高,各个团队之间的沟通和和谐成本会很高,因为一个团队的修改大概会影响到其他团队的工作。解耦可以使各个团队相对独立地进行开发,提高开发效率,减少团队之间的冲突。
3)解耦能带来什么



  • 增强系统的可扩展性:解耦后的系统,各个模块可以独立地进行扩展。当需要添加新的功能时,可以在不影响现有模块的条件下,开发新的模块并将其集成到系统中。比方,在一个社交系统中,原本只有用户注册、登录和发布动态的功能,解耦后如果要添加私信功能,只需要开发私信模块并与现有系统进行得当的集成即可。
  • 提升系统的可测试性:模块之间的低耦合使得每个模块可以独立进行测试。开发职员可以针对单个模块编写测试用例,而不需要考虑其他模块的影响,这样可以更方便地发现和定位标题,提高测试的效率和准确性。
  • 提高系统的稳定性:当系统中某个模块出现故障时,由于模块之间的耦合度低,故障的影响范围会被限定在该模块内部,不会容易扩散到其他模块,从而包管了整个系统的稳定性。
   比方,在一个分布式系统中,如果某个服务模块出现标题,不会导致整个系统瓦解,其他服务模块仍然可以正常运行。
  

  • 促进技术的多样性和机动性:解耦后的系统答应各个模块采用差别的技术和架构。差别的模块可以根据自身的特点和需求选择最符合的技术栈,这样可以充实发挥各种技术的优势,提高系统的团体性能和质量。
   比方,前端界面模块可以利用 Vue.js 等框架,而后端数据处理模块可以利用 Python 的 Django 框架。
  总结:

        解耦是软件设计的 “减法艺术”,通过公道拆分、抽象和异步化,让系统像搭积木一样机动。尽管需要衡量成本,但对于中长期项目而言,解耦是实现可持续演进的关键。

三、我们为什么要采用多层架构?

开发中利用多层架构(如表现层、业务逻辑层、数据访问层等)主要基于以下缘故原由:
1.职责分离,降低复杂度




  • 单一职责原则:每层专注于特定功能(如 UI、业务规则、数据利用),代码结构更清晰。
  • 示例:修改数据库时只需调整数据层,不影响前端页面或业务逻辑。
2. 提高可维护性



  • 模块化开发:各层独立维护,功能迭代或修复弊端时更高效。
  • 团队协作:差别团队可并行开发差别层(如前端团队负责表现层,后端团队负责逻辑层)。
3. 增强扩展性



  • 机动扩展:新增功能(如支持新付出方式)只需在业务层添加代码,不影响其他层。
  • 技术选型自由:各层可采用差别技术(如前端用 React,后端用 Java,数据库用 MySQL)。
4. 便于测试



  • 单位测试:可单独测试业务逻辑层或数据层,无需启动整个系统。
  • 隔离故障:某层错误(如数据库连接失败)不会直接导致其他层瓦解。
5. 提升安全性



  • 分层防护:表现层过滤输入,业务层验证权限,数据层加密存储,形成多层安全屏蔽。
  • 权限控制:差别层可设置差别访问权限(如前端无法直接访问数据库)。
6. 优化性能



  • 独立优化:各层可针对性优化(如数据层缓存、业务层异步处理、表现层 CDN 加快(可见: CDN加快是什么?如何通过CDN提高网站访问速度?-CSDN博客))。
  • 负载均衡:业务层可横向扩展,支持高并发哀求。
总结:

多层架构通过分工协作、模块化设计和机动扩展,降低了大型系统的复杂度,同时提升了可维护性、安全性和性能。尽管增加了初期开发成本,但对中长期项目而言,是衡量利弊后的抱负选择。




免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

三尺非寒

金牌会员
这个人很懒什么都没写!
快速回复 返回顶部 返回列表