2012-01-05 5 views
0

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

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

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

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

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

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

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

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

Ste,

ответ

1

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

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

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

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

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

0

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

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

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

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

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

+0

Спасибо за ответ, я не планировал использовать PostSharp изначально, чтобы избежать отражения и генерировать весь необходимый код, но моя компания не будет платить за любое предприятие, к сожалению. Попробуйте Reflection, и попробуйте и получите некоторые метки! – Steoates

0

Чтение this Отклик от Marc Я бы предположил, что Reflection должно быть хорошо для большинства приложений.

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

+0

Я обновил это; p –

0

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

Есть две фазы в вашей проблеме:

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

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

Смежные вопросы