简体   繁体   English

依赖注入和 Mediatr 与 Azure 函数结合使用效率低吗?

[英]Is dependency injection and Mediatr in combination with Azure Functions inefficient?

I'm in early steps on my Azure journey.我在我的 Azure 旅程中处于早期阶段。 The way I understand functions is that they're a serverless solution that is only run when actually needed.我理解函数的方式是它们是一种无服务器解决方案,仅在实际需要时运行。 After performing their logic they "shut down" again.在执行了他们的逻辑后,他们再次“关闭”。 This is cheaper compared to something like an App Service, which is always running, even if there's no requests.与始终运行的应用服务(即使没有请求)相比,这更便宜。

My current situation: I have a solution set up in a DDD design similar to Microsoft's eshoponcontainers solution.我目前的情况:我在 DDD 设计中设置了一个类似于 Microsoft 的 eshoponcontainers 解决方案的解决方案。 I have a webapi project that only has super thin controllers, that simply pass their input to Mediatr, which passes it to different projects for validation and business logic.我有一个 webapi 项目,它只有超薄控制器,只需将输入传递给 Mediatr,Mediatr 将其传递给不同的项目进行验证和业务逻辑。 All my controller methods look like this:我所有的 controller 方法如下所示:

[HttpGet]
[ProducesResponseType(StatusCodes.Status200OK)]
[ProducesResponseType(StatusCodes.Status404NotFound)]
public async Task<IActionResult> GetById(string id)
{
    // Mediator instantiated via DI in the controller constructor
    var result = await Mediator.Send(new GetByIdQuery { Id = id });
    return Ok(result);
}

It's trivial for me to remove this webapi project, and replace it with an Azure Functions project that also takes input from an HTTP Trigger and pass it to Mediatr.删除这个 webapi 项目对我来说是微不足道的,并将其替换为 Azure Functions 项目,该项目也从 HTTP 触发器获取输入并将其传递给 Mediatr。 My dependency injection stuff is set up in a different project, independent from webapi so that's easily inserted in my Azure Functions project as well.我的依赖注入东西设置在不同的项目中,独立于 webapi,因此也可以轻松插入到我的 Azure Functions 项目中。 All my functions look like this:我所有的功能都是这样的:

public class GetId
{
    private readonly IMediator _mediator;

    public GetId(IMediator mediator)
    {
        _mediator = mediator;
    }

    [FunctionName("GetById")]
    public async Task<IActionResult> Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] string id,
        ILogger log)
    {
        var result = await _mediator.Send(new GetByIdQuery { AgreementId = id });
        return new OkObjectResult(result);
    }
}

But isn't this terrible from a cost perspective?但从成本的角度来看,这不是很糟糕吗? Based on my limited understanding, every time the Azure Function is started, it will create my substantial DI container all over again.根据我有限的了解,每次启动 Azure Function 时,它都会重新创建我的实体 DI 容器。 This means I'm paying a lot for CPU time that's doing DI setup, instead of my actual business logic.这意味着我为进行 DI 设置的 CPU 时间付出了很多,而不是我的实际业务逻辑。 Or am I missing something?还是我错过了什么?

Leaving aside the web API vs Azure Functions discussion, what you're doing is rather bizarre: accepting a message so that you can use Mediatr to manually fire an event based on that message's contents.撇开 web API 与 Azure 功能讨论不谈,您正在做的事情相当奇怪:接受消息以便您可以使用基于事件的消息内容手动触发 Mediatr。

Azure already has built-in functionality for exactly this: Event Grid, Event Hub, or Service Bus. Azure 已经为此提供了内置功能:事件网格、事件中心或服务总线。 Create one of these resources, publish events/messages to them instead of to a web API/Azure Functions, and replace your Mediatr event listeners with Event Grid/Event Hub/Service Bus listeners.创建这些资源之一,将事件/消息发布到它们而不是 web API/Azure 函数,并将您的 Mediatr 事件侦听器替换为事件网格/事件中心/服务总线侦听器。 Then you don't need a web API or Azure Functions at all.那么你根本不需要 web API 或 Azure 功能。

In regards to the actual question, there are many concerns that come with Azure Functions - inability to use ASP.NET Core middleware is a big one.关于实际问题,Azure 功能带来了许多问题 - 无法使用 ASP.NET 核心中间件是一个大问题。 You might save on resource usage, but honestly Azure is so cheap that such a saving is likely to not be worth it.您可能会节省资源使用量,但老实说 Azure 是如此便宜,以至于这样的节省可能不值得。 (I suggest you look at the actual pricing, as opposed to assuming that Azure Functions will save you money simply because it's not always-on.) And no, DI container construction doesn't cost much CPU at all - if it does, you have bigger architectural problems. (我建议您查看实际定价,而不是假设 Azure 函数会因为它并非始终在线而为您省钱。)不,DI 容器构建根本不会花费太多 CPU - 如果是这样,您有更大的架构问题。

There are always tradeoffs, and nothing is free.总是有权衡,没有什么是免费的。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM