До какой степени отражения следует использовать?

Question

У нас очень сложный сценарий в проекте. Мы использовали много отражений в нашем проекте.

У нас есть ..

• Валидационная структура, управляемая Атрибутами и Отражением
• Методы расширения, которые преобразуют DataRow в объект Entity, используя атрибуты и отражение, и наоборот. То же самое мы сделали для DataTable и EntityCollections.
• Интерфейс IComparer, реализованный в универсальном классе EntityComparer, который использует отражение для сравнения двух объектов Entity.

Как и в приведенных выше сценариях, мы использовали отражения во многих других частях нашего приложения. После использования отражения мы заметили, что приложение выполняет больше циклов обработки с отражением.

До какой степени мы должны использовать Reflection в нашем проекте? Какие области проекта наиболее подвержены влиянию рефлексии с точки зрения обработки? Где отражение не окажет никакого влияния на производительность? Есть ли какие-либо рекомендации по использованию Reflection?

Answer 1

Отражение мощно, но имеет недостатки. В общем, попробуйте написать код без него, но он чрезвычайно полезен для библиотек «каркаса», где у вас мало знаний о том, какими будут реальные объекты; например:

• Инструменты ORM / DAL (загрузка / сохранение произвольных данных)
• привязки данных
• сериализация

Существуют штрафы за производительность с произвольным отражением, но если вы собираетесь это сделать лоты (в вашей библиотеке и в узком цикле), вы можете уменьшить это:

• с использованием Delegate.CreateDelegate (как типизированный делегат; не использовать DynamicInvoke)
• путем написания динамического IL
• с помощью Expression в .NET 3.5

И, конечно, любой такой код должен кэшироваться и использоваться повторно (вы не хотите компилировать + выполнять для каждого вызова; только первый - остальные должны просто выполняться).

Или есть библиотеки, которые абстрагируют это; например, HyperPropertyDescriptor оборачивает пользовательский IL (для доступа к элементу) в привычный PropertyDescriptor API - делая это очень быстро, но безболезненно. Ваш вопрос упоминает таблицы данных и сущности; который звучит лот как этот предыдущий вопрос , где я сделал некоторые метрики, используя HyperDescriptor, со сводкой (в миллисекундах):

Vanilla 27179
Hyper   6997

Итак, мой "дубль":

• в приложении ; очень мало - в крайнем случае, обычно
• в вашей общей библиотеке / библиотеках ; при необходимости (отмечая, что интерфейсы и т. д. предпочтительнее, где это возможно)

Answer 2

Мой совет - всегда пытаться сначала найти объектно-ориентированное решение, а не прибегать к рефлексии при первой возможности. Может быть проще выполнить что-то с помощью рефлексии, но, как правило, код становится более организованным с помощью ОО-решения, и вы избавляетесь от накладных расходов на рефлексию.

За годы моей работы в качестве разработчика я только дважды использовал рефлексию ... Первым было получить доступ к какой-то закрытой переменной, чтобы получить ход загрузки веб-запроса. Вторым было динамическое создание экземпляров объектов при чтении из устройства чтения данных, которое я позже был рад заменить на общее решение.

Answer 3

Ваше нефункциональное требование / QoS должно определять, целесообразно ли использовать отражение и как с моим комментарием, тестом, тестом, тестом (юнит, тест производительности и т. Д.). Если ваш клиент доволен работой, я бы сказал, пойти на это. При правильном использовании он может и дает определенный прирост производительности.

Лично я не буду использовать рефлексию, когда смогу.

Answer 4

Отражение может обеспечить реальные преимущества для расширяемости и гибкости. При использовании отражения наблюдается снижение производительности, но это не должно отталкивать вас мгновенно, особенно если оно дает вам больше преимуществ. Старайтесь использовать рефлексию с осторожностью, но не думайте, что вам будет больно пользоваться, когда вам это нужно. Эта статья хороша на эту тему: http://www.west -wind.com / блог / сообщений / 351.aspx

Answer 5

Если обувь подходит, тогда наденьте ее ... Если она решает проблему под рукой и не вызывает избыточной обработки, измеренной каким-либо тестированием (предпочтительно профилировщиком), тогда не беспокойтесь об этом , Есть много проблем, которые легко решаются с помощью рефлексии.

Единственное правило, которое я имею в отношении решения не использовать отражение, - это использование его для получения свойств, к которым у вас обычно нет доступа (т. Е. К закрытым свойствам в чужом классе).