3 min read

AutoMapper Dependency Injection into Azure Functions

Justin Yoo

DISCLAIMER: This post is purely a personal opinion, not representing or affiliating my employer's.

Handling DTO (Data Transfer Object) is one of core tasks while developing an application especially to interact with database or external APIs. As you know, using DTO is particularly good for data encapsulation. In other words, we only expose data structure we want to share. AutoMapper really helps those DTO transformation. AutoMapper also supports ASP.NET Core's dependency injection feature out-of-the-box, which we can utilise in Azure Functions. In this post, I'm going to show how to use AutoMapper DI in Azure Functions.

The sample codes used here in this post can be found at here.

AutoMapper Dependency Injection

The code used here is an Azure Function code that calls secret keys from Azure Key Vault. Without using AutoMapper, the whole SecretBundle object will be returned to the API caller, which might not be nice. Instead of returning the SecretBundle object, returning a customised DTO containing only necessary information would be a good idea. Let's have a look at this code. The SecretProfile inheriting Profile defines mapping details.

public class SecretProfile : Profile
{
public SecretProfile()
{
this.CreateMap<SecretBundle, SecretModel>()
.ForMember(d => d.Id, o => o.MapFrom(s => s.Id))
...
;
}
}
view raw profile.cs hosted with ❤ by GitHub

This SecretProfile is registered through the AddAutoMapper() extension method, which looks for an assembly. By doing so, every single class inheriting Profile is automatically registered into the IoC container.

public class AppModule : Module
{
public override void Load(IServiceCollection services)
{
...
services.AddAutoMapper(Assembly.GetAssembly(this.GetType()));
...
}
}
view raw appmodule.cs hosted with ❤ by GitHub

This Azure Functions code uses Aliencube.AzureFunctions.Extensions.DependencyInjection for its dependency injection management.

Injecting IMapper at the Function Level

After defining the IoC container like above, each function simply loads those dependencies and use them. The IFunctionFactory registers all the dependencies when the trigger is called. Then within the trigger, it invokes the IGetSecretFunction instance to run all the business logic, which is to retrieve secret keys from Azure Key Vault.

public static class SecretsHttpTrigger
{
// Register dependencies through the fucntion factory.
public static IFunctionFactory Factory = new FunctionFactory<AppModule>();
[FunctionName(nameof(GetSecret))]
public static async Task<IActionResult> GetSecret(
[HttpTrigger(AuthorizationLevel.Function, "get", Route = "secrets/{name}")] HttpRequest req,
string name,
ILogger log)
{
IActionResult result;
try
{
...
// Invokes function containing all business logics
result = await Factory.Create<IGetSecretFunction, ILogger>(log)
.InvokeAsync<HttpRequest, IActionResult>(req, options)
.ConfigureAwait(false);
...
}
return result;
}
}
view raw httptrigger.cs hosted with ❤ by GitHub

The GetSecretFunction instance simply loads the IMapper instance and use it.

public class GetSecretFunction : FunctionBase<ILogger>, IGetSecretFunction
{
...
private readonly IMapper _mapper;
public GetSecretFunction(AppSettings settings, IMapper mapper, IKeyVaultClient kv)
{
...
this._mapper = mapper ?? throw new ArgumentNullException(nameof(mapper));
}
public override async Task<TOutput> InvokeAsync<TInput, TOutput>(TInput input, FunctionOptionsBase options = null)
{
...
var mapped = this._mapper.Map<SecretModel>(secret);
...
}
}
view raw function.cs hosted with ❤ by GitHub

So far, we have walked through how we can inject AutoMapper into Azure Functions. As you can see, Azure Functions seamlessly uses the DI feature from ASP.NET Core, so there is nothing really hard for it. All you need is to define mapping details and register them before use.