休眠+迁移工作流程
我正在寻求围绕 NHibernate 和相对频繁更改的架构来完善我的工作流程，以及如何最好地处理这个问题 - 我希望将相同的解决方案应用于生产系统，所以我认为我需要一个迁移引擎而不仅仅是架构更新。
我想知道的是如何尽可能地改进工作流程，以便我做尽可能少的工作来使我的数据库与我的域模型同步。 tarantino 脚本方法看起来不错，但似乎没有办法从我的 nHibernate 映射生成更新脚本，所以我只能手工编写脚本或使用 redgate sql 比较之类的工具。我是否缺少任何可以让脚本生成阶段的工作变得更轻松的东西？
谢谢， 克里斯
I'm looking to refine my workflow around NHibernate and a relatively frequently changing schema, and how best to deal with this - I would like the same solution to apply to production systems, so I think I need a migration engine rather than just Schema Update.
What I want to know is how i can refine the workflow as far as possible so that I'm doing as little work as possible to get my database in sync with my domain model. The tarantino approach of scripts looks nice, but there doesn't seem to be a way to generate the update script from my nHibernate mappings, so i'm down to hand crafting a script or using a redgate sql compare like tool. Is there anything I'm missing that would make life easier around the script generation stage?
Thanks,
Chris
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我自己没有使用过任何.net 迁移工具，但是几年前，当我在业余时间尝试 Ruby on Rails 时，我看到了迁移与我们当时在工作中使用的 t-sql 脚本相比的好处。
I haven't used any of these migration tools for .net myself, but when trying out Ruby on Rails on my spare time some years ago, I saw the benefits of migrations compared to the t-sql scripts we used at my job at the time.
在我最近参与的一个项目中，我们发现迁移与 VCS 分支和 NHibernate 相结合可能会导致一些令人头疼的问题和缺点。
我们所做的就是设置 NHibernate 来生成每个自动构建（针对开发环境）的模式以及一些数据加载。
对于生产环境，我们有一个基于当前架构和所需架构的脚本，它生成一个包含必要字段和修改的迁移。
In a recent project I've been, we've discovered that migrations, combined with VCS branching and NHibernate can cause several headaches and drawbacks along the way.
What we did was to set up NHibernate to generate the schema with each automated build (for the development environment) along with some data loading.
For the production environment, we had a script that based on the current schema and the desired schema, it generated one migration with the necessary fields and modifications.
我们使用SQL Compare。这是付费的，但恕我直言，值得投资。保持每个生成的脚本组织良好 - 即带有时间戳 - 并且您可以为任何已发布版本生成数据库的好方法。
这是我们通常的流程
查看命令行选项，因为它们是通过 VS 构建事件来自动化该过程非常方便。
We use SQL Compare. It is paid for but worth the investment imho. Keep each of the generated scripts well organized - i.e. timestamped - and you get yourself a good way of generating the database for any of the released versions.
This is our usual flow
Have a look at the command line options as they are quite handy to automate the process via VS build events.