Appeler tous les gourous de l'automapper!
J'aimerais pouvoir cartographier l'objet A à l'objet B différemment en fonction du contexte au moment de l'exécution. En particulier, j'aimerais ignorer certaines propriétés dans une case de mappage et avoir toutes les propriétés mappées dans un autre cas.
Ce que je ressens est que mapper.createmap peut être appelé avec succès dans les différents cas de cartographie, une fois que Createmap est appelé, la carte d'une paire de types particuliers est définie et n'est pas modifiée ultérieurement en suivant des appels de CauseMap qui pourrait Décrivez la cartographie différemment.
J'ai trouvé un poteau de blog qui préconise mapper.reset () pour contourner le problème, cependant, la nature statique de la classe Maper signifie que ce n'est qu'une question de temps avant une collision et une collision.
Y a-t-il un moyen de faire cela?
Ce que je pense avoir besoin, c'est appeler mapper.createmap une fois par AppDomain, puis pour pouvoir appeler mapper.map avec des astuces sur quelles propriétés doivent être incluses / exclues.
En ce moment, je pense à modifier le code source en écrivant une classe de mappage non statique qui contient l'instance de configuration de mappage basée. Mauvaise performance, mais le fil sûr.
Quelles sont mes options. Ce qui peut être fait? Fadificper semble si prometteur.
3 Réponses :
La classe Maper est simplement une fine wrapper sur une configuration et des objets Mapptengine. Vous pouvez créer des instances séparées d'objets de configuration / Mapptengine (toujours à l'aide de singletons) et d'utiliser votre conteneur de choix COI pour charger le bon besoin nécessaire.
La meilleure option est toujours d'utiliser différents types de destinations. La partie très difficile à soutenir vraiment cette fonctionnalité est la nature hiérarchique inhérente des cartes de type. L'objet de niveau supérieur peut avoir un profil de mappage, tandis que les niveaux inférieurs ne le font pas. Certains entre les deux pourraient l'avoir ou non, etc.
Pour moi, cela ressemble à une meilleure conception pourrait être d'avoir plusieurs classes de destination (peut-être héritant d'une base commune ou la mise en œuvre d'une interface commune)
Si les propriétés non mappées ne seront jamais utilisées dans l'une des variantes, vous pourrait les laisser entièrement (ce qui donne la garantie de compilation qu'ils ne sont pas utilisés par erreur), lancer une exception quand ils sont accessibles (pas aussi bon que d'une garantie de temps de compilation, mais parfois vous avez besoin de l'interface complète à mettre en œuvre) ou même utiliser une valeur de remplacement p>
Par exemple:. p>
public class SourceSummaryDTO : SourceDTO
{
public string Name {get;set;}
public BigEntity
{
get{throw new NotSupportedException();}
set{throw new NotSupportedException();}
}
}
juste pour compléter la réponse de Jimmy Voici le code nécessaire pour utiliser STABAPPER sans le mappeur statique
// Configuration
var autoMapperCfg = new AutoMapper.ConfigurationStore(new AutoMapper.TypeMapFactory(), AutoMapper.Mappers.MapperRegistry.AllMappers());
var mappingEngine = new AutoMapper.MappingEngine(autoMapperCfg);
//Usage example
autoMapperCfg.CreateMap<ClassA, ClassB>();
var b = mappingEngine.Map<ClassB>(a);
@Omu: Vous et votre "ValeurInjectorCer" commencent à être très ennuyeux. Vous n'êtes pas obligé de répondre à chaque question de MODApper avec votre plugin pour ValueInjectorate (ne doit-il pas être valuinjector). Je suis personnellement éteint par cela et ne le regarderais même pas en raison de votre tactique. Ce n'est tout simplement pas un homme professionnel.