序列化 NHibernate 配置对象 - 检测过期还是按需重建？
我一直在使用 序列化nhibernate 配置对象（还讨论了此处 和 此处）将我的应用程序启动速度从大约 8 秒缩短到 1 秒。我也用的是flutter-nhibernate，所以路径更像是
- 代码中的ClassMap类定义
- fluidconfiguration
- xml
- nhibernate配置
- 配置序列化到磁盘。
这样做的问题是，人们会面临映射过时的风险 - 如果我更改映射但忘记重建序列化配置，那么我最终会在没有意识到的情况下使用旧映射。这并不总是会在测试过程中导致立即且明显的错误，并且多次发现和修复错误行为确实很痛苦。
有谁知道我如何能够检测我的类映射是否已更改，以便我可以立即发出警告/错误或根据需要重建它？
目前，我正在将已编译程序集的时间戳与序列化配置进行比较。这将拾取映射更改，但不幸的是，它会产生大量误报率，因为对代码的任何更改都会导致过期标志。我无法将类映射移动到另一个程序集，因为它们紧密集成到业务逻辑中。
这已经困扰我一段时间了，所以我想知道是否有人有任何建议？
I've been using serialized nhibernate configuration objects (also discussed here and here) to speed up my application startup from about 8s to 1s. I also use fluent-nhibernate, so the path is more like
- ClassMap class definitions in code
- fluentconfiguration
- xml
- nhibernate configuration
- configuration serialized to disk.
The problem from doing this is that one runs the risk of out of date mappings - if I change the mappings but forget to rebuild the serialized configuration, then I end up using the old mappings without realising it. This does not always result in an immediate and obvious error during testing, and several times the misbehaviour has been a real pain to detect and fix.
Does anybody have any idea how I would be able to detect if my classmaps have changed, so that I could either issue an immediate warning/error or rebuild it on demand?
At the moment I am comparing timestamps on my compiled assembly against the serialized configuration. This will pickup mapping changes, but unfortunately it generates a massive false positive rate as ANY change to the code results in an out of date flag. I can't move the classmaps to another assembly as they are tightly integrated into the business logic.
This has been niggling me for a while so I was wondering if anybody had any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为什么不直接创建序列化配置文件作为构建过程的一部分并将其包含在部署包中？
它仍然是序列化的以便快速加载，但保证您每个版本都有最新版本。
Why not just create the serialized configuration file as part of your build process and include it in your deployment package?
It's still serialized for quick-loading but you're guaranteed to have the latest version for every build.