Динамический язык. Runtime vs Reflection

Ответ 1

Считываемый\поддерживаемый код

Конечно, в моем опыте.

Меньше строк кода.

Не значительно, но это поможет.

Влияет на производительность приложения.

Очень немного. Но даже близко к тому, как отражается.

Динамическое ключевое слово внутренне является оболочкой Reflection.

Полностью не соответствует действительности. Динамическое ключевое слово использует динамическое время выполнения библиотеки.

[Изменить: исправление в соответствии с комментарием ниже]

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

Динамическое типирование может превратиться в размножающуюся почву для поиска ошибок.

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

Влияет на совместимость с предыдущими версиями .NET

Не верно. Я имею в виду, что вы не сможете скомпилировать свой код с более старых версий, но если вы хотите это сделать, вы должны использовать старые версии в качестве базы и перекомпилировать ее, а не наоборот. Но если вы хотите использовать библиотеку .NET 2, вам не следует запускать слишком много проблем, если вы включаете объявление в app.config/web.config.

Одним из важных преимуществ, которых вам не хватает, является улучшенная совместимость с компонентами COM/ATL.

Ответ 2

Пожалуйста, помогите мне в том, разумны ли плюсы и минусы, с которыми я сталкивался, или нет?

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

Вместо того, чтобы думать об этом с точки зрения плюсов и минусов, подумайте об этом в более нейтральных терминах. Вопрос, который я задал бы: "Каковы различия между использованием Reflection и использованием динамического типа?"

Сначала: с Reflection вы получите именно то, что вы просили. С динамикой вы получаете то, что сделал бы компилятор С#, если бы ему была предоставлена ​​информация о типе во время компиляции. Это потенциально две совершенно разные вещи. Если у вас есть MethodInfo для определенного метода и вы вызываете этот метод с определенным аргументом, то это метод, который вызывается, период. Если вы используете "динамический", то вы просите DLR работать во время выполнения, что мнение компилятора С# о том, что является правильным методом вызова. Компилятор С# может выбрать метод, отличный от того, который вам действительно нужен.

Во-вторых: с Reflection вы можете (если ваш код предоставлен достаточно высоким уровнем доверия) делают частное отражение. Вы можете использовать частные методы, читать частные поля и т.д. Является ли это хорошей идеей, я не знаю. Это, конечно, кажется мне опасным и глупым, но я не знаю, что такое ваша заявка. С динамикой вы получите поведение, которое вы получите от компилятора С#; частные методы и поля не отображаются.

В-третьих: с Reflection код, который вы пишете, выглядит как механизм. Похоже, вы загружаете источник метаданных, извлекаете некоторые типы, извлекаете информацию о некоторых методах и вызываете методы на объектах получателя через информацию метода. Каждый шаг на пути выглядит как работа механизма. С динамикой каждый шаг выглядит как бизнес-логика. Вы вызываете метод на приемнике так же, как и в любом другом коде. Что важно? В некотором коде механизм на самом деле является самым важным. В некотором коде бизнес-логика, которую реализует механизм, является самой важной вещью. Выберите технику, которая подчеркивает правильный уровень абстракции.

В-четвертых: затраты на производительность различны. С Reflection вы не получаете никакого кэшированного поведения, а это означает, что операции, как правило, медленнее, но для сохранения кеша нет затрат на память, и каждая операция примерно одинакова. С DLR первая операция очень медленная, так как она проводит огромный анализ, но анализ кэшируется и повторно используется. Это потребляет память в обмен на увеличение скорости в последующих вызовах в некоторых сценариях. Какой правильный баланс скорости и памяти используется для вашего приложения, я не знаю.

Ответ 3

Существует 4 больших различия между динамикой и отражением. Ниже приводится подробное объяснение того же. Ссылка http://www.codeproject.com/Articles/593881/What-is-the-difference-between-Reflection-and-Dyna

Пункт 1. Осмотреть VS Invoke

Отражение может делать две вещи: одно может проверить метаданные, а во-вторых, оно также имеет возможность вызывать методы во время выполнения. В Dynamic мы можем использовать только методы. Поэтому, если я создаю программное обеспечение, такое как визуальная студия IDE, тогда размышление - это путь. Если мне просто нужен динамический вызов из моего кода С#, то лучшим вариантом будет динамика.

Точка 2. Частный Vs Public Invoke

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

Точка 3. Кэширование

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

Точка 4. Статические классы

Динамический экземпляр специфичен: у вас нет доступа к статическим членам; вы должны использовать Reflection в этих сценариях.

Ответ 4

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

Динамическое ключевое слово подрывает инструменты автоматического рефакторинга и делает более важными модульные тесты с высоким охватом; в конце концов, компилятор ничего не проверяет, когда вы его используете. Это не такая уж большая проблема, когда вы взаимодействуете с очень стабильным или по сути динамически типизированным API, но это особенно неприятно, если вы используете ключевое слово dynamic для доступа к библиотеке, чей API может измениться в будущем (например, любой код, который вы сами пишете).

Используйте ключевое слово экономно, где это имеет смысл, и убедитесь, что такой код имеет достаточные модульные тесты. Не используйте его там, где он не нужен, или где вывод типа (например, var) может сделать то же самое.

Изменить: Вы упомянули ниже, что вы делаете это для плагинов. Managed Extensibility Framework была разработана с учетом этого - это может быть лучший вариант, ключевое слово dynamic и отражение.

Ответ 5

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

Ответ 6

То, как я вижу все ваши минусы для использования динамических, кроме взаимодействия со старыми версиями .NET, также присутствует при использовании Reflection:

Влияет на производительность приложения

В то время как это влияет на производительность, так и с использованием Reflection. Из того, что я помню, DLR более или менее использует Reflection при первом доступе к методу/свойству вашего динамического объекта для заданного типа и кэширует целевую пару типа/доступа, так что более поздний доступ - это просто поиск в кеше, что делает его более быстрым затем Reflection

Динамическое ключевое слово внутренне является оболочкой Reflection

Даже если это было правдой (см. выше), как это будет отрицательным моментом? Независимо от того, завершает ли оно или нет. Отражение не должно влиять на ваше приложение в любом существенном вопросе.

Динамическое типирование может превратиться в место размножения, чтобы трудно найти ошибки

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

Влияет на совместимость с предыдущими версиями .NET

Для этого вы должны сами решить, насколько это важно для вас.