asp.net core系列 71 Web架构分层指南

  • 时间:
  • 浏览:2
  • 来源:极速快3_快3手机版_极速快3手机版

一.概述

  本章Web架构分层指南,参考了“Microsoft应用应用应用程序体系行态指南”(该书是在60 9年出版的,当时出版是为了帮助开发人员和架构师快一点 速,更低风险地使用Microsoft平台和.NET Framework设计和构建有效,高质量的应用应用应用程序)。其实已过去十年了,技术架构已更新(如流行的DDD/CQRS模式,微服务,容器),但web分层思想还是一样可取,下面是4个 “传统N分层设计”架构图,该架构在2010年左右是最流行的,包括了表现层presentation,服务层services,业务层business,数据访问层data,横切关注点cross,如下所示:

  对比传统多层或三层.net web架构,下图是当前流行的.net web微服务架构,在web应用应用程序分层之上还涵盖了容器,web api网关,各服务对应的数据存储(sqlserver,redis,mongoDB),web应用应用程序有web api并结合应用了DDD\CQRS分层模式,以及系统各种上端件。

  下图是4个 订单微服务站点,涵盖了繁复的cqrs分层,淡蓝色长方格是表示cqrs分层的职责,包括了查询 Queries viewModels和命令Command Domain-Model以及上层的应用服务层Application,如下所示

  1.1 逻辑分层设计架构类型

    (1) 最传统的分层是经典三层设计,包括表现层,业务层,数据层.

    (2) 基于服务的出理 方案SOA,公开应用应用应用程序业务功能的服务层,服务层在业务层之上。

    (3) 基于领域驱动设计的DDD\CQRS分层模式

    (4) 微服务架构

     这4种web分层架构是不断的演化改变 ,每这一 分层架构并总要 独立的思想,它涵盖了演化并且的架构分层思想。从并且三层架构到现在的微服务架构,是适应每个时代互联网业务实现的需求。

功能

SOA

微服务

组件大小

大块业务逻辑

单独任务或小块业务逻辑

耦合

通常松耦合

时不时松耦合

公司架构

任何类型

小型、专注于功能交叉团队

管理

着重中央管理

着重分散管理

目标

确保应用能够交互操作

执行新功能、快速拓展开发团队

.Web分层设计步骤

  1.分层策略

    (1)分层粒度是选则分层策略的关键第一步.

    (2)在逻辑分层中, 多层是在同一应用应用程序中运行,这都能够利用更高性能的通信机制。相似 通过组件接口直接调用。前要小心保持层之间的封装和松散耦合。

    (3)在物理分层中,选则为宜的通信机制,该机制考虑到通信延迟并保持之间的松散耦合。

    (4)多层中,考虑它们之间如保相互影响,将确保性能和灵活性之间的良好平衡。

  2.选则前要层

    最常用的土妙招是将表现层,服务层,业务层和数据访问层功能分离到单独的层中。某些应用应用应用程序还引入了各种组件像缓存、日志、消息队列等。

  3.决定如保采集各层和组件

    对于web体系架构,一般总要 在4个 物理层,非要在必要时,才应在不同的物理层上分布层和组件。这是实现分布式部署的常见因为包括安全策略,物理约束,共享业务逻辑和可伸缩性。

  4.选则是否是前要折叠层

    一般规则是您应始终将功能分组到层中。在某些情形下,4个 层都能够充当代理或传递层,提供封装和松散耦合,而不提供血块功能。并且,通过分离该功能,您都能够稍后对其进行扩展,而对设计中的某些层几乎这麼影响,如:应用服务层。

  5.选则层之间引用的规则

    在分层策略时,您前要定义层如保相互交互的规则(交互是指:各层引用的关系)。指定交互规则的主要因为是最小化依赖性并消除循环引用。并且应该遵循以下土妙招之一:

    (1)自上而下的交互

      较高级别的层都能够与下面的层交互,并且较低级别的层不应该与上端的层交互。此规则将帮助您出理 层之间的循环依赖关系,以及要降低层之间的依赖性。

    (2)严格的互动

      每个层前要仅与下面的层进行交互。此规则将强制严格分离关注点,其中每个层仅知道下面的层。此规则的好处是对层界面的修改只会影响上端的层。不可能 您正在设计4个 将随着时间的推移进行修改以引入新功能并且您希望最大限度地减少那先 更改的影响的应用应用应用程序,不可能 您正在设计不可能 分布在不同物理层上的应用应用应用程序,请考虑使用此土妙招。

    (3)松散的互动

      较高级别的层都能够绕过层直接与较低级别的层交互。这都能够提高性能,但也会增加依赖性换句话说,对较低级别层的修改都能够影响上端的多个层

    下图是4个 示例:该web架构示例是使用了 cqrs 模式,涉及到了事件源es, 事件源实现本因该分离到命令域和查询域, 而项目中应用服务层直接引用了底层数据访问层Dapper(绕过了领域层),  从前底层Dapper接口土妙招的修改或去掉 EF将影响顶层应用服务层,这属于第这一 "松散的互动"。 应该推荐使用第这一 自上而下的交互。

  6.选则跨领域问题报告 报告

    定义层后,前要标识跨越层的功能。此功能通常被描述为横切关注点,包括日志记录,缓存,验证,身份验证和异常管理。选则应用应用应用程序中的每个横切关注点非常重要,并设计单独的组件以尽不可能 地管理那先 问题报告 报告 。此土妙招可帮助您实现更好的可重用性和可维护性。

    如下图所示:NLog与Redis是具体实现组件,实现了Common层中的日志和缓存接口,Common层只是横切组件,是跨层可重用的。像Ioc也是横切组件。 下图层的名称这麼标识跨越层的功能,不可能 是GFNetCore.Infra.CrossCutting.IoC 从前命名会更好。

  7.定义层之间的接口

    为层定义接口时,主要目标是强制层之间的松散耦合。这因为着层不应暴露另一层不可能 依赖的实物细节。相反,层的接口应设计为通过提供隐藏层内组件细节的公共接口来最小化依赖性。某些隐藏称为抽象,有某些不同的土妙招来实现它。以下设计土妙招可用于定义层的接口:

    (1)抽象接口

      通过定义抽象基类或接口类来实现,该类充当具体类的类型定义。该类型定义了4个 公共接口,该层的所有使用者都使用该接口与该层进行交互。这是这一 面向接口编程,相似 :表现层调用应用服务层的接口。表现层在CustomerController控制器中如下所示(通过依赖注入后,构造土妙招来实例):

     //表现层调用应用服务层ApplicationService
        private readonly ICustomerAppService _customerAppService;

        public CustomerController(ICustomerAppService customerAppService, 
                                  INotificationHandler<DomainNotification> notifications) : base(notifications)
        {
            _customerAppService = customerAppService;
        }

      但在项目中,为了繁复开发量,表现层调用应用服务层的实现类(违反了面向接口编程)。表现层在CustomerController控制器中如下所示:

        //调用应用服务层ApplicationService
        private readonly CustomerAppService _customerAppService = null;

        //日志对象
        public readonly ILoggerEX _logger;

        public CustomerController(INotificationHandler<DomainNotification> notifications,
                                  ILoggerEX logger,
                                  CustomerAppService customerAppService)
            : base(notifications)
        {
            _customerAppService = customerAppService;
            _logger = logger;
        }

    (2)依赖倒置

      这是这一 编程风格,是面向接口编程的实现,依赖倒置的应用如:DDD\CQRS, 层依赖于层接口,而总要 层依赖于从前层的实现。依赖注入模式是依赖性反转的常见实现。依赖性反转土妙招提供了灵活性,都能够帮助实现可插入设计,不可能 依赖性是通过配置而总要 代码组成的。它还都能够最大化可测试性,不可能 您都能够轻松地将具体测试类注入到设计的不同层中。

      依赖性是通过配置的,如下代码所示,由CommandRepository类来实现ICommandRepository接口:

        services.AddScoped<ICommandRepository<CommandModels.Customer>, CommandRepository<CommandModels.Customer>>();
        services.AddScoped<IQueryRepository<QueryModels.Customer>, QueryRepository<QueryModels.Customer>>();

    (3) 基于消息

      都能够使用基于消息的通信来实现接口并提供层之间的交互,.net技术如:wcf, web services, msmq它们支持跨物理和应用应用程序边界的交互(以xml的soap格式传输),但这是对于09年流行的web架构。现在基于消息多数用web api技术,是面向微服务开发(以json的rest api)。

 参考资料

   分层应用应用应用程序指南