Сериализованные объекты конфигурации NHibernate - обнаружить устаревшие или восстановить по требованию? - PullRequest
3 голосов
/ 17 марта 2010

Я использовал сериализованные объекты конфигурации nhibernate (также обсуждаемые здесь и здесь ), чтобы ускорить запуск моего приложения с 8 секунд до 1 секунды. Я также использую fluent-nhibernate, поэтому путь больше похож на

  1. Определения классов ClassMap в коде
  2. fluentconfiguration
  3. XML
  4. Конфигурация nhibernate
  5. конфигурация сериализована на диск.

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

Кто-нибудь знает, как я смогу определить, изменились ли мои карты классов, чтобы я мог сразу же выдать предупреждение / ошибку или перестроить его по требованию?

В данный момент я сравниваю метки времени на моей скомпилированной сборке с сериализованной конфигурацией. Это приведет к изменениям в отображении захвата, но, к сожалению, оно генерирует значительный процент ложных срабатываний, поскольку ЛЮБОЕ изменение кода приводит к появлению устаревшего флага. Я не могу переместить карты классов в другую сборку, поскольку они тесно интегрированы в бизнес-логику.

Это какое-то время мучало меня, поэтому мне было интересно, есть ли у кого-нибудь какие-либо предложения?

1 Ответ

0 голосов
/ 10 мая 2010

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

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

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