本文主要是介绍Web开发：ABP框架中的服务调用原则--避免服务之间的直接依赖，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
示意图
（Service之间可以相互调用，使用依赖倒置原则：例如某个服务可注入到另一个服务，用法：private readonly IyyyService _yyyService;）
命名约定
- WebAPI 控制器: 建议命名为
XXXXController或XXXXManagementController（也有的命名为XXXXManagementService），主要用于处理HTTP请求。 - 业务逻辑层服务(BLL): 命名为
XXXXService，主要用于增删改查和写基本逻辑，通常会被 Web API 控制器调用。 - 数据访问层仓储(DAL): 使用
XXXXRepository命名， ORM（对象关系映射）处理，很可能用到反射之类的技术。
接口定义
- 通常，为了实现解耦和便于测试，建议为业务逻辑层服务 (
XXXXService) 和数据访问层仓储 (XXXXRepository) 定义接口。这些接口可以放在Application.Contracts命名空间下。 - 责任: 定义服务和仓储层的合同，以便于实现依赖注入和松耦合。
参数设计
- 在设计业务逻辑层服务（BLL）的方法时，推荐使用列表类型作为输入参数和返回值，这样可以更好地支持批量操作，并提高代码的重用性。对于复杂的数据交互，可以考虑使用专门的 DTO（数据传输对象）。
调用关系
- 一个 WebAPI 控制器不允许调用另一个 WebAPI 控制器。
- 直接的控制器间调用可能会导致架构复杂度增加，维护困难，调试困难。更好的做法是通过服务层 (
XXXXService) 进行协调，将所需的业务逻辑封装在服务层内部，然后由需要的控制器调用相应的服务方法来获取或处理数据。 - 如果两个Webapi控制器相互注入，会导致循环依赖从而无法解析依赖，导致程序无法启动或启动后增加额外开销，影响系统稳定性
反例：
[HttpGet]
[Route("GetMenuAsync")]//MenuManageService.cs
public async Task GetMenuAsyncc(IputDto input)
{var com_list = (await _componentManageService.GetListAsync());
}[HttpGet]
[Route("GetListAsync")]//componentManageService.cs
public async Task<PagedResultDto<ComponentTypeDto>> GetListAsync(ComponentTypeDto input)
{//省略方法
}综上所述，在实际开发过程中，尽量避免控制器之间的直接调用，而是通过共享的服务层来协调不同的业务需求，这样可以确保系统架构更加清晰、易于维护。
这篇关于Web开发：ABP框架中的服务调用原则--避免服务之间的直接依赖的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
