何时添加额外的“服务”或 BLL 层？答案

【问题标题】：When to add an additional "service" or BLL layer?何时添加额外的“服务”或 BLL 层？
【发布时间】：2017-10-27 19:37:21
【问题描述】：

我有一个 Web API 控制器，例如：

    [HttpGet]
    [Route("accounts", Name = "GetAccounts")]
    public async Task<IHttpActionResult> GetAccounts()
    {
        var query = Request.RequestUri.PathAndQuery.Split('/')[2];

        var response = await Client.HTTPCLIENT.GetAsync(Client.HTTPCLIENT.BaseAddress + query);

        if (!response.IsSuccessStatusCode)
        {
            return NotFound();
        }

        var readAsAsync = response.Content.ReadAsAsync<object>();
        if (readAsAsync == null)
        {
            return NotFound();
        }

        var result = await readAsAsync;
        return Ok(result);
    }

我的问题是我是否应该简化控制器并将此逻辑推入新的服务/业务逻辑层？

我的用例是让这段代码在服务结构上的微服务中运行。

向该架构添加另一层会是多余/不必要的复杂性，有什么好处吗？

【问题讨论】：

对于复杂的逻辑和大型应用程序，以及单独的业务逻辑和表示逻辑（如 MVC），您应该使用另一层
使用服务架构时，您可能正在寻找微服务架构。例如，您可以使用有状态服务来存储和检索数据或使用数据库作为后端的无状态服务。或用于某些业务逻辑的无状态/有状态服务。这取决于您对微服务有多大的看法。那么告诉我，你为什么选择服务结构而不是网络应用？
在服务结构中，一个常见的场景是在一个节点类型上运行 api，该节点类型具有运行计算服务的其他规范。不知道你的确切要求很难说。
什么逻辑？ “未找到”逻辑？
@Mardoxx，不，特别是 var response = await Client.HTTPCLIENT.GetAsync(…………如果我不得不在此行之后立即致电第三方怎么办并聚合然后返回结果？在这种情况下，我会将所有这些因素都分解到单独的 AccountService 中吗？

标签： c# .net asp.net-web-api visual-studio-2017 azure-service-fabric

【解决方案1】：

据我所知，这个控制器唯一要做的就是调用另一个服务并返回结果。我在这里看不到任何可以提取到其他服务的内容。

我总是会问，您从拥有更多服务中得到什么好处，付出的代价是什么？就物理机资源使用、开发成本和维护而言，往返服务的成本相对较高。

【讨论】：