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

Question

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

У нас есть ..

• Validation Framework движимый Атрибуты и отражение
• методы расширения, которые transaforms в DataRow на объект Entity с использованием атрибутов и отражения, и наоборот. То же самое мы сделали для DataTable и EntityCollections.
• Интерфейс IComparer реализован на универсальном классе EntityComparer, который использует отражение для сравнения двух объектов Objectity OBjects.

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

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

Answer 1

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

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

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

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

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

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

Vanilla 27179 
Hyper 6997 

Так мой "взять":

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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