Отражение позволяет проверять во время выполнения ту же информацию, что и компилятор, во время компиляции. Следовательно, все, что вы можете сделать с отражением, может быть сделано без отражения во время компиляции. Это не означает, что отражение не имеет смысла: вы можете не знать, какой именно вопрос вы хотите задать до выполнения.
Если вы знаете что-то во время компиляции, выразите его в системе типов. Это позволит вам ловить ошибки во время компиляции. Например,
string propVal = myObj.SomeProperty;
Здесь мы говорим, что мы знаем наверняка, во время компиляции, что myObj имеет свойство SomeProperty, которая имеет тип, который присваиваемые string - и на самом деле, хотя не видно здесь мы также должны указать тип класса или интерфейса myObj.
string propVal = (string)myObj.GetType()
.GetProperty("SomeProperty")
.GetValue(myObj, null);
Здесь мы говорим, что myObj может иметь то же свойство - или он не может (и в этом случае мы получим исключение во время выполнения).
Второй, используя отражение, выглядит прикладом-уродливым, но в C# 4.0 он будет выглядеть практически идентичным. Он часто считается слишком медленным, но это зависит от контекста и, вероятно, будет менее справедливым для динамических функций в C# 4.0.
Реальное различие остается, однако: статически типизированная версия помогает нам находить ошибки во время компиляции, вместо того, чтобы откладывать это открытие до времени выполнения.
Поэтому, если вы хотите в полной мере использовать систему статического типа для обнаружения ошибок во время компиляции, попробуйте указать свои предположения с помощью системы типов, что эквивалентно высказыванию: избегайте отражения, кроме случаев, когда это действительно необходимо.
Я вижу много мнений, но не обсуждаю лучшие практики. –
Нам просто нравится видеть наше имя в печати. Видеть? -> –
Некоторые из вас указали, что отражение имеет место в рамках, тестировании, mocks и т. Д. Как насчет в бизнес-приложениях? – Mank