AI 助理
文档备案控制台
开发者社区 开发与运维 文章 正文

.NET应用架构设计—重新认识分层架构（现代企业级应用分层架构核心设计要素）

2017-11-14 1057
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介：

阅读目录：

  • 1.背景介绍

  • 2.简要回顾下传统三层架构

  • 3.企业级应用分层架构（现代分层架构的基本演变过程）

    • 3.1.服务层中应用契约式设计来解决动态条件不匹配错误（通过契约式设计模式来将问题在线下暴露出来）

    • 3.2.应用层中的应用控制器模式（通过控制器模式对象化应用层的职责）

    • 3.3.业务层中的命令模式（事务脚本模式的设计模式运用，很好的隔离静态数据）

  • 4.服务层作为SOA契约公布后DTO与业务层的DomainModel共用基本的原子类型

  • 5.两种独立业务层职责设计方法（可以根据具体业务要求来搭配）

    • 5.1.在应用层中的应用控制器中协调数据层与业务层的互动（业务层将绝对的独立）

    • 5.2.将业务层直接依赖数据层的关系使用IOC思想改变数据层依赖业务层（业务层将绝对独立）（比较优雅）

  • 6.总结

1.背景介绍

接触分层架构有段时间了，从刚开始的朦朦胧胧的理解到现在有一定深度的研究后，觉得有必要将自己的研究成果分享出来给大家，互相学习，也是对自己的一个总结。

我们每天面对的项目结构可以说几乎都是分层结构的，或者是基于传统三层架构演变过来的类似的分层结构，少不了业务层、数据层，这两个层是比较重要的设计点，看似这两个层是互相独立的，但是这两个层如何设计真的还有很多比较微妙的地方，本文将分享给大家我在工作中包括自己的研究中得出的比较可行的设计方法。

2.简要回顾下传统三层架构

其实这一节我本来不打算加的，关于传统三层架构我想大家都应该了解或者很熟悉了，但是为了使得本文的完整性，我还是简单的过一下三层架构，因为我觉得它可以使得我后面的介绍有连贯性。

传统三层架构指将一个系统按照不同的职责划分层三个基本的层来分离关注点，将一个复杂的问题分解成三个互相协作的单元来共同的完成一个大任务。

1.显示层：用来显示数据或从UI上获取数据；该层主要是用来处理数据显示和特效用的，不包括任何业务逻辑。

2.业务层：业务层包含了系统中所有的核心业务逻辑，不包括任何跟数据显示、数据存取相关的代码逻辑。

3.数据层：用来提供对具体的数据源引擎的访问，主要用来直接存取数据，不包括业务逻辑处理。

其实用文字描述这三个层的基本职责还很是比较容易的，但是不同的人如何理解并设计这三个层就形态各异了，反正我是看过很多各种各样的分层结构，各有各的特点，从某个角度讲都很不错，但是都显得有点乱，因为没有一个统一的架构模式来支撑，代码中充满了对分层架构的理解错位的地方，比如：经常看见将“事物脚本”模式和“表模块”模式混搭使用的，导致我最后都不知道把代码写在哪里，提取出来的代码也不知道该放到哪个对象里。

层虽简单但是要想运用的好不容易，毕竟我们还是站在一个比较高的层面比较笼统的层面来谈论分层结构的，一旦落实到代码上就完全不一样了，用不用接口来隔离各层，接口放在哪个层里，这些都是很微妙的，当然本文不是为了说明我所介绍的设计是多么的好，而是给大家一个可以参考的例子而已。

言归正传，三个层之间的调用要严格按照“上层只能调用直接下层，不能够越权，而下层也不能够调用自己的上层”，这是基本的层结构的调用约束，只有这样才能保证一个好的代码结构。显示层只能调用业务层，业务层也只能调用数据层，其实就是这么简单，当然具体的代码设计也可以大概归纳为两种，第一种是实例类或静态类直接调用；第二种是每个层之间加上接口来隔离每个层，使得测试、部署容易点，但是如果用的不好的话效果不大反而会增加复杂度，还不如直接使用静态类来的直接点，但是用静态类来设计业务类会使多线程操作很难实施，稍微不注意就会串值或报错。

3.企业级应用分层架构（现代分层架构的基本演变过程）

上节中我们基本了解了传统三层架构的类型和职责，本节我们来简单介绍一下现代企业应用分层架构的类型和职责。

随着企业应用的复杂度增加，在原有三层架构上逐渐演化出现在的面向企业级的分层架构，这种架构能很好的支持新的技术和代码上的最佳实践。

在传统的三层结构中的业务层之上多了一个应用层也可是说是服务层，该层是为了直接隔离显示层来调用业务层，因为现在的企业应用基本上都在往互联网方向发展，对业务逻辑的访问不会在是从进程内访问了，而是需要跨越网络来进行。

有了这一层之后会让原本显示层调用业务层的过程变得灵活很多，我们可以添加很多灵活性在里面，更为重要的是显示层和业务层两个独立的层要想完全独立是必须要有一个层来辅助和协调他们之间的互动的。在最早的三层架构的书籍中其实也提到了“服务层”来协调的作用，为什么我们很多的项目都不曾出现过，当我自己看到书上有讲解后才恍然大悟。（该部分可以参考：《企业应用架构模式》【马丁.福勒】；第二部分，第9章“服务层”）

图1：（逻辑分层）

wKiom1PzURnQcDkOAAEHZNqrGoM534.jpg

应用层中包含了服务的设计部分，应用层的概念稍微大一点，里面不仅不含了服务还包含了很多跟服务不相关的应用逻辑，比如：记录LOG，协调基础设施的接入等等，就是将服务层放宽了理解。

图2：（项目结构分层）

wKioL1PzUk7BSePYAAGN2XXks9A055.jpg

在应用层中包含了我们上述所说的”服务“，将”服务层“放宽后形成了现在分层架构中至关重要的”应用层“。应用层将负责整体的协调”业务层“和”数据层“及“基础设施”，当然还会包括系统运行时环境相关的东西。

3.1.服务层中应用契约式设计来解决动态条件不匹配错误（通过契约式设计模式来将问题在线下暴露出来）

此设计方法主要是想将动态运行时条件不匹配错误在线下自动化回归测试时就暴露出来。因为服务层中的契约可能会面临着被修改的危险性，所以我们无法知道我们本次上线的契约中是否包含了不稳定的条件不匹配的危险。

利用契约式设计模式可以在调用时自动的执行契约发布方预先设定的契约检查器，契约检查器分为前置条件检查器和后置条件检查器；我们来看一个简单的例子；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
using  System;
using  System.Collections.Generic;
using 
System.Linq;
using  System.Text;
using  System.Threading.Tasks;
namespace  CompanySourceSearch.Service.Contract
{
     using 
CompanySourceSearch.ServiceDto.Request;
     using 
CompanySourceSearch.ServiceDto.Response;
public  interface  ISearchComputer
     {
         GetComputerByComputerIdResponse 
GetComputerByComputerId(GetComputerByComputerIdRequest request);
     }
}

在服务契约中我定义了一个用来查询企业中电脑资源的接口，好的设计原则就是不要直接暴露查询字段而是要将其封装起来。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
namespace  CompanySourceSearch.ServiceDto
{
     public  abstract  class 
ContractCheckerBase
     {
         private  Func< bool > 
checkSpecification;
         public  Func< bool > 
CheckSpecification
         {
             get
             {
                 return  this .checkSpecification;
             }
             private  set
             {
                 this .checkSpecification = value;
             }
         }
public  void  SetCheckSpecfication(Func< bool > checker)
         {
             CheckSpecification = checker;
         }
public  virtual  bool  RunCheck()
         {
             if 
(CheckSpecification !=  null )
                 return  CheckSpecification();
return  false ;
         }
     }
}

然后定义了一个用来表示契约检查器的基类，这里纯粹是为了演示目的，代码稍微简单点。服务契约的请求和响应都需要通过继承这个检查器类来实现自身的检查功能。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
namespace  CompanySourceSearch.ServiceDto.Request
{
     public  class 
GetComputerByComputerIdRequest : ContractCheckerBase
     {
         public 
long  ComputerId {  get ;  set ; }
public  GetComputerByComputerIdRequest()
         {
             this .SetCheckSpecfication(() => ComputerId > 
0 /*ComputerId>0的检查规则*/ );
         }
     }
}

Request类在构造函数中初始化了检查条件为：ComputerId必须大于0。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
namespace  CompanySourceSearch.ServiceDto.Response
{
     using 
CompanySourceSearch.ServiceDto;
public  class  GetComputerByComputerIdResponse : ContractCheckerBase
     {
         public  List<ComputerDto> ComputerList {  get ;  set ; }
public  GetComputerByComputerIdResponse()
         {
             this .SetCheckSpecfication(() => ComputerList !=  null  && 
ComputerList.Count > 0);
         }
     }
}

同样Response类也在构造函数中初始化了条件检查器为：ComputerList不等于NULL并且Count要大于0。还是那句话例子是简单了点，但是设计思想很不错。

对前置条件检查器的执行可以放在客户端代理中执行，当然你也可以自行去执行。后置条件检查器其实在一般情况下是不需要的，如果你能保证你所测试的数据是正确的，那么作为自动化测试是应该需要的，当时维护一个自动化测试环境很不容易，所以如果你用后置条件检查器来检查数据动态变化的环境时是不太合适的。

3.2.应用层中的应用控制器模式（通过控制器模式对象化应用层的职责）

应用层设计的时候大部分情况下我们都喜欢使用静态类来处理,静态类有着良好的代码简洁性,而且还能带来一定的性能提升。但是从长远来考虑静态类存在一些潜在的问题，数据不能很好的隔离，重复代码不太好提取，单元测试不太好写。

为了能够在很长的一段时间内似的项目维护性很高的情况下还是建议将应用控制器使用实例类设计，这里我喜欢使用“应用控制器”来设计。它很形象的表达了协调前端和后端的职责，但是具体不处理业务逻辑，与MVC中的控制器很像。

1
2
3
4
5
6
7
8
9
10
11
12
13
namespace  CompanySourceSearch.ApplicationController.Interface
{
     using  CompanySourceSearch.Service.Contract;
     using 
CompanySourceSearch.ServiceDto.Response;
     using 
CompanySourceSearch.ServiceDto.Request;
public  interface  ISearchComputerApplicationController
     {
         GetComputerByComputerIdResponse 
GetComputerByComputerId(GetComputerByComputerIdRequest request);
     }
}

在应用控制器中我们定义了一个用来负责上述查询Computer资源的的控制器接口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
namespace  CompanySourceSearch.ApplicationController
{
     using 
CompanySourceSearch.ApplicationController.Interface;
     using 
CompanySourceSearch.ServiceDto.Request;
     using 
CompanySourceSearch.ServiceDto.Response;
public  class  SearchComputerApplicationController : 
ISearchComputerApplicationController
     {
         public 
GetComputerByComputerIdResponse 
GetComputerByComputerId(GetComputerByComputerIdRequest request)
         {
             throw  new  NotImplementedException();
         }
     }
}

控制器实现类。这样可以很清晰的分开各个应用控制器，这样对服务实现来说是个很不错的提供者。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
namespace  CompanySourceSearch.ServiceImplement
{
     using 
CompanySourceSearch.Service.Contract;
     using 
CompanySourceSearch.ServiceDto.Response;
     using 
CompanySourceSearch.ServiceDto.Request;
     using 
CompanySourceSearch.ApplicationController.Interface;
public  class  SearchComputer : ISearchComputer
     {
         private 
readonly  ISearchComputerApplicationController 
_searchComputerApplicationController;
public  SearchComputer(ISearchComputerApplicationController 
searchComputerApplicationController)
         {
             this ._searchComputerApplicationController = 
searchComputerApplicationController;
         }
public  GetComputerByComputerIdResponse 
GetComputerByComputerId(GetComputerByComputerIdRequest request)
         {
             return 
_searchComputerApplicationController.GetComputerByComputerId(request);
         }
     }
}

服务在使用的时候只需要使用IOC的框架将控制器实现直接注入进来就行了，当然这里你可以加上AOP用来记录各种日志。

通过将控制器按照这样的方式进行设计可以很好的进行单元测试和重构。

3.3.业务层中的命令模式（事务脚本模式的设计模式运用，很好的隔离静态数据）

在一般的企业应用中大部分的业务层都是使用"事务脚本"模式来设计,所以这里我觉得有个很不错的模式可以借鉴一下。但是很多事务脚本模式都是使用静态类来处理的，这一点和控制器使用静态类相似了，代码比较简单，使用方便。但是依然有着几个问题，数据隔离，不便于测试重构。

将事务脚本使用命令模式进行对象化，进行数据隔离，测试重构都很方便，如果你有兴趣实施TDD将是一个不错的结构。

1
2
3
4
5
6
7
8
9
10
namespace  CompanySourceSearch.Command.Interface
{
     using 
CompanySourceSearch.DomainModel;
public  interface  ISearchComputerTransactionCommand
     {
         List<Computer> FilterComputerResource(List<Computer> 
Computer);
     }
}

事务命令控制器接口，定义了一个过滤Computer资源的接口。你可能看见了我使用到了一个DominModel的命名空间，这里面是一些跟业务相关的且通过不断重构抽象出来的业务单元（有关业务层的内容后面会讲）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
namespace  CompanySourceSearch.Command
{
     using 
CompanySourceSearch.Command.Interface;
public  class  SearchComputerTransactionCommand : CommandBase, 
ISearchComputerTransactionCommand
     {
         public 
List<DomainModel.Computer> 
FilterComputerResource(List<DomainModel.Computer> Computer)
         {
             throw  new  NotImplementedException();
         }
     }
}

使用实例类进行业务代码的组装将是一个不会后悔的事情，这里我们定义了一个CommandBase类来做一些封装工作。

应用控制器同样和服务类一样使用IOC的方式使用业务命令对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
namespace  CompanySourceSearch.ApplicationController
{
     using 
CompanySourceSearch.ApplicationController.Interface;
     using 
CompanySourceSearch.ServiceDto.Request;
     using 
CompanySourceSearch.ServiceDto.Response;
     using 
CompanySourceSearch.Command.Interface;
public  class  SearchComputerApplicationController : 
ISearchComputerApplicationController
     {
         private  readonly 
ISearchComputerTransactionCommand _searchComputerTransactionCommand;
         public  SearchComputerApplicationController(ISearchComputerTransactionCommand 
searchComputerTransactionCommand)
         {
             this ._searchComputerTransactionCommand = 
searchComputerTransactionCommand;
         }
public  GetComputerByComputerIdResponse 
GetComputerByComputerId(GetComputerByComputerIdRequest request)
         {
             throw  new  NotImplementedException();
         }
     }
}

到目前为止每个层之间坚持使用面向接口编程。

4.服务层作为SOA契约公布后DTO与业务层的DomainModel共用基本的原子类型

这里有个矛盾点需要我们平衡,当我们定义服务契约时会定义服务所使用的DTO,而在业务层中为了很好的凝聚业务模型我们也定义了部分领域模型或者准确点讲，在事务脚本模式的架构中我们是通过不断重构出来的领域模型,它封装了部分领域逻辑。所以当服务中的DTO与领域模型中的实体需要使用相同的原子类型怎么办？比如某个类型的状态等等。

如果纯粹的隔离两个层面，我们完全可以定义两套一模一样的原子类型来使用，但是这样会带来很多重复代码，难以维护。如果不定义两套那么又将这些共享的类型放在哪里比较合适，放在DTO中显示不合适，业务模型是不可能引用外面的东西的，如果放在领域模型中似乎也有点不妥。

这里我是采用将原子类型独立一个项目来处理的，可以类似于"CompanySourceSearch.DomainModel.ValueType"这样的一个项目，它只包含需要与DTO进行共享的原子值类型。

5.两种独立业务层职责设计方法（可以根据具体业务要求来搭配）

之前我们没有谈业务层的设计，这里我们重点讲一下业务层的设计包括与数据层的互操作。

从应用层开始考虑，当我们需要处理某个逻辑时从应用控制器开始可能就会认为直接进入到服务层了，然后服务层再去调用数据层，其实这只是设计的一种方式而已。这样的设计方式好处就是简单明了，实现起来比较方便。但是这种方法有个问题就是业务层始终还是依赖数据层的，业务层的变动依然会受到数据层的影响。还有一个问题就是如果这个时候你使用不是“事务脚本”模式来设计业务层的话也会自然而然的写成过程式代码，因为你将原本用来协调的应用控制器没有做到该做的事情，它其实是用来协调业务层和数据层的，我们并不一定非要在业务层中去调用数据层，而是可以将业务层需要的数据从控制器中获取好然后传入到业务层中去处理，这和直接在业务层中去调用数据层是差不多的，只不过是写代码的时候不能按照过程式的思路来写了。

不管我们是使用事务脚本模式还是表模块模式或者当下比较流行的领域模型模式，都可以使用这种方法进行设计。

5.1.在应用层中的应用控制器中协调数据层与业务层的互动（业务层将绝对的独立）

我们将在应用控制器中去调用数据层的方法拿到数据然后转换成领域模型进行处理。

1
2
3
4
5
6
7
8
9
namespace  CompanySourceSearch.Database.Interface
{
     using 
CompanySourceSearch.DatasourceDto;
public  interface  IComputerTableModule
     {
         List<ComputerDto> GetComputerById( long  cId);
     }
}

我们使用"表入口“数据层模式来定义了一个用来查询Computer的方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
namespace  CompanySourceSearch.ApplicationController
{
     using 
CompanySourceSearch.ApplicationController.Interface;
     using 
CompanySourceSearch.ServiceDto.Request;
     using 
CompanySourceSearch.ServiceDto.Response;
     using 
CompanySourceSearch.Command.Interface;
     using 
CompanySourceSearch.Database.Interface;
     using 
CompanySourceSearch.DatasourceDto;
     using 
CompanySourceSearch.Application.Common;
public  class  SearchComputerApplicationController : 
ISearchComputerApplicationController
     {
         private  readonly 
ISearchComputerTransactionCommand _searchComputerTransactionCommand;
         private  readonly  IComputerTableModule _computerTableModule;
         public 
SearchComputerApplicationController(ISearchComputerTransactionCommand 
searchComputerTransactionCommand,
             IComputerTableModule 
computerTableModule)
         {
             this ._searchComputerTransactionCommand = 
searchComputerTransactionCommand;
             this ._computerTableModule = 
computerTableModule;
         }
public  GetComputerByComputerIdResponse 
GetComputerByComputerId(GetComputerByComputerIdRequest request)
         {
             var  result =  new  GetComputerByComputerIdResponse();
var  dbComputer = 
this ._computerTableModule.GetComputerById(request.ComputerId); //从数据源中获取Computer集合
             var  dominModel = 
dbComputer.ConvertToDomainModelFromDatasourceDto(); //转换成DomainModel
var  filetedModel = 
this ._searchComputerTransactionCommand.FilterComputerResource(dominModel); //执行业务逻辑过滤
return  result;
}
     }
}

控制器中不直接调用业务层的方法，而是先获取数据然后执行转换在进行业务逻辑处理。这里需要澄清的是，此时我是将读写混合在一个逻辑项目里的，所以大部分的查询没有业务逻辑处理，直接转换成服务DTO返回即可。将读写放在一个项目可以共用一套业务逻辑模型。当然仅是个人看法。

这个是业务层将是完全独立的，我们可以对其进行充分的单元测试，包括迁移和公用，甚至你可以想着领域特定框架发展。

5.2.将业务层直接依赖数据层的关系使用IOC思想改变数据层依赖业务层（业务层将绝对独立）（比较优雅）

上面那种使用业务层和数据层的方式你也许觉得有点别扭，那么就换成使用本节的方式。

以往我们都是在业务层中调用数据层的接口来获取数据的，此时我们将直接依赖数据层，我们可以借鉴IOC思想，将业务层依赖数据层进行控制反转，让数据层依赖我们业务层，业务层提供依赖注入接口，让数据层去实现，然后在业务命令对象初始化的时候在动态的注入数据层实例。

如果你已经习惯了使用事物脚本模式来开发项目，没关系，你可以使用此模式来将数据层彻底的隔离出去，你也可以试着在应用控制器中帮你分担点事物脚本的外围功能。

6.总结

文章中分享了本人觉得到目前来说比较可行的企业应用架构设计方法，并不能说完全符合你的口味，但是可以是一个不错的参考，由于时间关系到此结束，谢谢大家。




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





文章标签：
测试技术
技术小胖子
目录
相关文章
aliyun6145761485-44099
|
资源调度 前端开发 算法
鸿蒙OS架构设计探秘：从分层设计到多端部署
本文深入探讨了鸿蒙OS的架构设计，从独特的“1+8+N”分层架构到模块化设计，再到智慧分发和多端部署能力。分层架构让系统更灵活，模块化设计通过Ability机制实现跨设备一致性，智慧分发优化资源调度，多端部署提升开发效率。作者结合实际代码示例，分享了开发中的实践经验，并指出生态建设是未来的关键挑战。作为国产操作系统的代表，鸿蒙的发展值得每一位开发者关注与支持。
aliyun6145761485-44099
1402 86
想飞的雪糕
|
人工智能 前端开发 JavaScript
前端架构思考 ：专注于多框架的并存可能并不是唯一的方向 — 探讨大模型时代前端的分层式微前端架构
随着前端技术的发展，微前端架构成为应对复杂大型应用的流行方案，允许多个团队使用不同技术栈并将其模块化集成。然而，这种设计在高交互性需求的应用中存在局限，如音视频处理、AI集成等。本文探讨了传统微前端架构的不足，并提出了一种新的分层式微前端架构，通过展示层与业务层的分离及基于功能的横向拆分，以更好地适应现代前端需求。
想飞的雪糕
824 0
追逐时光者
|
C# Android开发 iOS开发
2025年全面的.NET跨平台应用框架推荐
2025年全面的.NET跨平台应用框架推荐
追逐时光者
1016 23
屋顶的咖啡猫
|
数据库
分层架构
表现层（Presentation Layer）：处理用户界面和用户交互逻辑。 业务逻辑层（Business Logic Layer）：处理业务相关的逻辑和规则。 数据访问层（Data Access Layer）：负责与数据库或其他数据源进行 [Something went wrong, please try again later.]。
屋顶的咖啡猫
511 2
众所周知
|
敏捷开发 缓存 中间件
.NET技术的高效开发模式，涵盖面向对象编程、良好架构设计及高效代码编写与管理三大关键要素
本文深入探讨了.NET技术的高效开发模式，涵盖面向对象编程、良好架构设计及高效代码编写与管理三大关键要素，并通过企业级应用和Web应用开发的实践案例，展示了如何在实际项目中应用这些模式，旨在为开发者提供有益的参考和指导。
众所周知
292 3
路边两盏灯
|
开发框架 监控 .NET
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install
路边两盏灯
511 5
小王老师呀
|
JSON 算法 安全
JWT Bearer 认证在 .NET Core 中的应用
【10月更文挑战第30天】JWT（JSON Web Token）是一种开放标准，用于在各方之间安全传输信息。它由头部、载荷和签名三部分组成，用于在用户和服务器之间传递声明。JWT Bearer 认证是一种基于令牌的认证方式，客户端在请求头中包含 JWT 令牌，服务器验证令牌的有效性后授权用户访问资源。在 .NET Core 中，通过安装 `Microsoft.AspNetCore.Authentication.JwtBearer` 包并配置认证服务，可以实现 JWT Bearer 认证。具体步骤包括安装 NuGet 包、配置认证服务、启用认证中间件、生成 JWT 令牌以及在控制器中使用认证信息
小王老师呀
797 2
源码星辰
|
JSON 前端开发 Java
Spring Boot框架中的响应与分层解耦架构
在Spring Boot框架中，响应与分层解耦架构是两个核心概念，它们共同促进了应用程序的高效性、可维护性和可扩展性。
源码星辰
603 3
蒋星熠Jaxonic
|
Cloud Native Serverless API
微服务架构实战指南：从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic，代码为舟的星际旅人。深耕微服务架构，擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验，探索技术演进的无限可能。
蒋星熠Jaxonic
1106 4
微服务架构实战指南：从单体应用到云原生的蜕变之路

热门文章

最新文章

  • 1
    浅析阿里云API网关的产品架构和常见应用场景
  • 2
    如何无缝迁移 SpringCloud/Dubbo 应用到 Serverless 架构
  • 3
    带你读《微服务架构设计模式》之二：服务的拆分策略
  • 4
    Redis混合存储产品与架构介绍
  • 5
    卷积神经网络架构：EfficientNet结构的特点
  • 6
    架构之道：人人都是架构师（1）
  • 7
    企业IT架构云平台实践与思考
  • 8
    飞天技术沙龙回顾：业务创新新选择，倚天Arm架构深入探讨
  • 9
    阿里云转发路由器Transit Router：构建云上高效、灵活且安全的网络架构之利器
  • 10
    第四章：OceanBase集群技术架构（分布式事务、MVCC、事务隔离级别）
  • 1
    ASP.NET Core Blazor 路由配置和导航
    850
  • 2
    Visual C++运行库、.NET Framework和DirectX运行库的作用及常见问题解决方案，涵盖MSVCP140.dll丢失、0xc000007b错误等典型故障的修复方法
    2366
  • 3
    AutoGen for .NET - 架构学习指南
    1300
  • 4
    Semantic Kernel .NET 架构学习指南
    1352
  • 5
    Microsoft .NET Framework 3.5、4.5.2、4.8.1,适用于 Windows 版本的 .NET,Microsoft C Runtime等下载
    2504
  • 6
    .NET技术深度解析：现代企业级开发指南
    775
  • 7
    提示缺少.NET Framework 3.5 安装错误：0x80070002、0x800F0950\0x80004002
    1326
  • 8
    windows离线安装.NET Framework 3.5(包括.net2.0和3.0)教程，（附离线安装包）
    62660
  • 9
    .NET Framework 3.5离线安装包合集下载
    8114
  • 10
    .NET Framework安装不成功，下载`NET Framework 3.5`文件，Microsoft Visual C++
    1809

    • 相关课程

    更多
  • Serverless 函数计算架构
  • 架构的演进
  • MySQL企业常见架构与调优经验分享
  • 企业Web常用架构LAMP-LNMP实战
  • 企业级互联网分布式系统应用架构学习
  • 高校精品课-上海交通大学 -企业级应用体系架构

    • 相关电子书

    更多
  • 云栖大会：开源 PolarDB 架构演进、关键技术与社区建设
  • 从技术到架构，云原生全面加速应用现代化
  • MaxCompute架构升级及开放性解读

    • 相关实验场景

    更多
  • 每个IT人都想学的“Web应用上云经典架构”实战
    • 下一篇
    一条命令迁移，帮你实现 OpenClaw 与 Hermes Agent 记忆互通！