Comment puis-je réutiliser le code pour mapper des propriétés enfants uniques aux DTO dans EF Core ?

Rationalisation du mappage DTO pour les propriétés enfants uniques dans EF Core

Entity Framework Core (EF Core) simplifie la conversion d'objet en DTO (Data Transfer Object) à l'aide d'arborescences d'expression. Cela fonctionne bien pour les collections enfants, mais le mappage des propriétés enfants uniques peut être moins intuitif. Cet article explore des solutions pour réutiliser le code et gérer efficacement ce scénario.

Le défi : cartographie des propriétés d'un seul enfant

Le mappage direct d'une seule propriété enfant à un DTO nécessite souvent des ajouts d'expressions manuels, ce qui conduit à un code répétitif. Prenons cet exemple :

<code class="language-csharp">public static Expression<Func<Model, ModelDto>> AsDto =>
    model => new ModelDto
    {
        ModelId = model.ModelId,
        ModelName = model.ModelName,
        ChildModels = model.ChildModels.AsQueryable().Select(ChildModel.AsDto).ToList(),
        AnotherChildModel = new AnotherChildModelDto // Manual mapping here
        {
            AnotherChildModelId = model.AnotherChildModel.AnotherChildModelId
        }
    };</code>

La solution : tirer parti des bibliothèques externes

Plusieurs bibliothèques fournissent des solutions élégantes en ajoutant efficacement une fonctionnalité de type .Select() pour des entités uniques, permettant ainsi la réutilisation du code :

1. Kit LINQ :

LINQKit permet l'expansion des expressions, en gérant dynamiquement le mappage d'un seul enfant.

<code class="language-csharp">[Expandable(nameof(AsDtoImpl))]
public static ModelDto AsDto(Model model)
{
    _asDtoImpl ??= AsDtoImpl().Compile();
    return _asDtoImpl(model);
}

private static Func<Model, ModelDto> _asDtoImpl;

private static Expression<Func<Model, ModelDto>> AsDtoImpl =>
    model => new ModelDto
    {
        ModelId = model.ModelId,
        ModelName = model.ModelName,
        ChildModels = model.ChildModels.AsQueryable().Select(ChildModel.AsDto).ToList(),
        AnotherChildModel = model.AnotherChildModel.AsDto() // LINQKit handles this
    };</code>

2. NeinLinq :

NeinLinq propose une approche similaire utilisant l'injection lambda.

<code class="language-csharp">[InjectLambda]
public static ModelDto AsDto(Model model)
{
    _asDto ??= AsDto().Compile();
    return _asDto(model);
}

private static Func<Model, ModelDto> _asDto;

private static Expression<Func<Model, ModelDto>> AsDto =>
    model => new ModelDto
    {
        ModelId = model.ModelId,
        ModelName = model.ModelName,
        ChildModels = model.ChildModels.AsQueryable().Select(ChildModel.AsDto).ToList(),
        AnotherChildModel = model.AnotherChildModel.AsDto() // NeinLinq handles this
    };</code>

3. DéléguéDécompilateur :

DelegateDecompiler propose une syntaxe plus concise utilisant des propriétés calculées. Notez que cette approche peut ne pas toujours convenir en fonction de la complexité de votre cartographie.

<code class="language-csharp">[Computed]
public static ModelDto AsDto(Model model)
=> new ModelDto
{
    ModelId = model.ModelId,
    ModelName = model.ModelName,
    ChildModels = model.ChildModels.AsQueryable().Select(ChildModel.AsDto).ToList(),
    AnotherChildModel = model.AnotherChildModel.AsDto() // DelegateDecompiler handles this
};</code>

Chaque bibliothèque nécessite une configuration et une configuration appropriées pour fonctionner correctement au sein de votre projet.

Conclusion :

Ces bibliothèques offrent des solutions efficaces pour réutiliser le code lors du mappage de propriétés enfants uniques aux DTO dans EF Core, réduisant ainsi la redondance et améliorant la maintenabilité. Le choix de la bonne bibliothèque dépend des préférences et de la complexité du projet. Le principal avantage est une approche cohérente et DRY (Don't Repeat Yourself) de la cartographie DTO.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!