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)) | |
... | |
; | |
} | |
} |
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())); | |
... | |
} | |
} |
This Azure Functions code uses Aliencube.AzureFunctions.Extensions.DependencyInjection
for its dependency injection management.
IMapper
at the Function Level
Injecting 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; | |
} | |
} |
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); | |
... | |
} | |
} |
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.