Аудит объектов

Question

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

-Класс реализует интерфейс

-Interfaces вынуждает класс переопределять некоторые методы для добавления свойств, требующих аудита, в список KeyValuePairs

-Класс также должен воссоздать состояние объектов из списка пар ключ-значение

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

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

Мой главный вопрос - я знаю, что люди всегда говорят, что рефлексия медленная, как медленно мы говорим? какие хиты производительности я получу, просматривая класс и просматривая атрибуты для свойства, а затем выполняя любую необходимую логику?

спасибо за любую помощь

Ste

Answer 1

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

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

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

Я бы начал с использования рефлексии и написал хороший набор модульных тестов, чтобы вы знали, что ваш код работает. Если производительность оказывается проблемой, вы можете использовать профилировщик Visual Studio для профилирования модульных тестов и выявления узких мест.

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

Answer 2

Отражение - это путь сюда.Если он слишком медленный (мера!), Вы можете добавить немного кеширования или в худшем случае сгенерировать Expression<T> и скомпилировать его.

В вашей задаче есть две фазы:

1. Выясните, какие свойства вам нужны, и верните список их PropertyInfo s.Вы должны сделать это только один раз для каждого типа, а затем вы можете кэшировать его.Таким образом, выполнение этого шага не имеет значения.
2. Получение значения каждого свойства с помощью PropertyInfo.GetValue.

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

Answer 3

Чтение этого ответа от Марка. Я бы предположил, что Reflection должна подойти для большинства потребностей приложения.

Прежде чем делать какие-либо фундаментальные изменения, я бы предложил запустить профилировщик, чтобы найти узкие места в вашем коде. Если вы определяете, что рефлексия / одитинг является основной проблемой, используйте IL Emit и попробуйте снова.

Answer 4

Если performance нормально или нет зависит от контекста вашего приложения.Поэтому трудно сказать, если это медленно или быстро для вас , вы должны попробовать это самостоятельно.

Скорее всего, IMO, это даст довольно приемлемую производительность, но опять же у меня нетИдея, где вы собираетесь его использовать.

Как и другие решения, которые приходят мне в голову, может быть:

• Sqlite, где сохранить key/value данные
• Аспектно-ориентированное программирование (например, PostSharp) для генерации данных за время компиляции .

Но первое, что попытается I , это отражение, простокак ты думаешь.