AutoMapper, как отобразить объект для возражения B по-другому В зависимости от контекста
Вызов всех гуру AutoMapper!
Я хотел бы смочь отобразить объект для возражения B по-другому в зависимости от контекста во времени выполнения. В частности, я хотел бы проигнорировать определенные свойства в одном случае отображения и иметь все свойства, отображенные в другом случае.
То, что я испытываю, является тем Картопостроителем. CreateMap можно назвать успешно в различных случаях отображения однако, после того как CreateMap называют, карта для конкретной пары типов установлена и впоследствии не изменяется путем следования за вызовами CreateMap, которые могли бы описать отображение по-другому.
Я нашел сообщение в блоге, которое защищает Картопостроитель. Сброс () для обхода проблемы, однако, статическая природа класса Картопостроителя означает, что это - только вопрос времени, прежде чем коллизия и катастрофический отказ произойдут.
Существует ли способ сделать это?
То, что я думаю, что мне нужно, должно назвать Картопостроитель. CreateMap однажды на appdomain, и позже, смочь назвать Картопостроитель. Карта с подсказками, о которых свойства должны быть включены / исключенный.
Прямо сейчас я думаю об изменении исходного кода путем записи нестатического класса отображения, который содержит отображающийся базирующийся экземпляр конфигурации. Низкая производительность, но ориентированный на многопотоковое исполнение.
Каковы мои опции. Что может быть сделано? Автокартопостроитель кажется настолько многообещающим.
2 ответа
Класс Mapper - это просто тонкая оболочка поверх объектов Configuration и MappingEngine. Вы можете создавать отдельные экземпляры объектов Configuration / MappingEngine (все еще используя синглтоны) и использовать выбранный вами контейнер IoC для загрузки нужного по мере необходимости.
Лучшим вариантом по-прежнему является использование разных типов адресатов. По-настоящему сложная часть реальной поддержки этой функции - это внутренняя иерархическая природа карт типов. Объект верхнего уровня может иметь профиль сопоставления, а объекты нижнего уровня - нет. Кто-то посередине может иметь это или нет и т. Д.
На мой взгляд, лучше всего было бы иметь несколько классов назначения (возможно, унаследованных от общей базы или реализации общего интерфейса).
Если несопоставленные свойства никогда не будут использоваться в одном из вариантов, вы может полностью исключить их (давая гарантию времени компиляции, что они не используются по ошибке), генерировать исключение при обращении к ним (не так хорошо, как гарантия времени компиляции, но иногда вам нужно реализовать полный интерфейс) или даже используйте заменяющее значение.
Например:
public class Source
{
public string Name {get;set;}
public BigEntity {get;set;}
/* other members */
}
public class SourceDTO
{
public string Name {get;set;}
public BigEntity {get;set;}
}
public class SourceSummaryDTO
{
public string Name {get;set;}
}
В качестве альтернативы вы можете сделать это:
public class SourceSummaryDTO : SourceDTO
{
public string Name {get;set;}
public BigEntity
{
get{throw new NotSupportedException();}
set{throw new NotSupportedException();}
}
}
Таким образом, вы можете передать SourceSummaryDTO, как если бы это был SourceDTO.
Условное заполнение свойств звучит для меня как рецепт неприятностей - я бы предпочел иметь классы, которые явно указывают, что они содержат, особенно с объектами передачи данных.
Для меня самое лучшее в Automapper - это возможность проверять сопоставления, а затем знать, что каждое свойство в целевых классах будет заполнено.