migrator.net vs fluttermigrator vs migsharp
我目前正在研究迁移框架/工具的可能选项。我喜欢上述框架所基于的 ruby 迁移的想法。
所以我想询问您的经验、意见以及它们之间的比较。您在生产中使用它们吗？
感谢您的回复。这个问题的目的是了解开发者社区中使用最多的工具，但迁移似乎不是这里的热门话题。
不管怎样，我决定使用 MigSharp，因为代码库看起来非常干净，而且很容易处理，并且内置了对 MS SQL CE 的支持。季军是 FluentMigrator，我无法为紧凑版生成工作示例。
干杯
I am currently investigating possible options of a migration framework/tool. I like the idea of ruby migrations on which the above frameworks are based.
So I am asking for your experience, opinions and maybe a comparison between them. Are you using them in production?
thanks for responses. The goal of this question was to get a feeling about which tools is used most in the developer community but it seems that migrations are not a hot topic here.
Anyway, I have decided to go with MigSharp as the codebase seem to be pretty clean and it is quite easy to handle and had build in support for MS SQL CE. Second runner up would have been FluentMigrator where I was not able to produce a working example for compact edition.
Cheers
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我在生产中使用 FluentMigrator，并且是 FM 的长期贡献者。我认为你的问题很笼统；更具体一些。此外，FM 有一个谷歌群组，如果您想要 FM 信息，该群组相当活跃。
我记得 FM 源自 migrator.net。它使用流畅的语法，并支持多个数据库。我们从 Rails 迁移中获得了一些灵感，但它绝对不是一个端口。值得一看。
我学到的一件事是不要将迁移与应用程序代码放在同一个程序集中。将它们分成一个迁移程序集，并使用它来迁移数据库。
此外，您应该始终在多个环境中工作，以避免直接针对生产运行的迁移出现问题。我总是至少有一个开发和生产环境，大多数时候还有一个测试环境。
I use FluentMigrator in production, and am a longtime contributor to FM. I think your question is to general; be more specific. Also, FM has a google group which is fairly active if you want FM information.
FM is derived from migrator.net, as I recall. It uses a fluent-syntax, and supports multiple databases. We have taken some inspiration from rails migrations, but it's definitely not a port. Worth checking out.
One thing I've learned is not to put your migrations in the same assembly as you app code. Separate them into a migration assembly, and use that for migrating your databases.
Also, you should always work on multiple environments to avoid problems with migrations run straight against production. I always have at least a development and production environment, and most of the time there is a testing environment as well.
我用的是mig#。
它运行良好，但您需要有一些使用指南 - 因为迁移可能会变得复杂。
我们在迁移结束时使用序列号，而不是日期时间戳。这是因为我们不知道日期时间戳是何时设置的（当他们开始源代码更改集时；在提交之前；中间的某个时间），不同的开发人员可以使用不同的方法。
Migration_0000034.cs 等名称可为您提供足够的空间。
I use mig#.
It works well, but you will need to have some guidelines for usage - as migrations can get complicated.
We use sequence number on the end of our migrations rather than a date-time stamp. This is because we don't know when the date time stamp was set (when they begun the source code change-set; just before committing; some time inbetween) different developers could use different approaches.
Names such as Migration_0000034.cs give you plenty of space.
在这一点上，我会坚持使用 migrator.net。我喜欢 FluentMigrator 的承诺，但它似乎没有比 migrator.net 更好的积极开发（请参阅在其 github 站点上陷入困境的问题和拉取请求）。
也没有简单的方法来执行 ExecuteScalar()。我会添加它，但我不想创建自己的分叉，而且我认为拉取请求实际上没有理由落在主服务器中。 （Execute.WithConnection 是一个 Action，因此它将按需触发，而不是在我需要它时触发）
所以对我来说，我将返回 migrator.net。
At this point, I would stick with migrator.net. I like the promise of FluentMigrator, but it seems to not have any better active development than migrator.net (see the issues and pull requests that have languished on their github site).
There is also no easy way to do an ExecuteScalar(). I'd add it, but I don't want to create my own fork, and I see no reason that a pull request would actually land in the master. (Execute.WithConnection is an Action so it will fire on demand rather than when I need it to fire)
So for me, I'm heading back to migrator.net.