migrator.net vs fluentmigrator vs migsharp

Question

我目前正在研究遷移框架/工具的可能選項。我喜歡上述框架基於的ruby遷移的想法。

所以我要求你的經驗，意見，也許他們之間的比較。你在生產中使用它們嗎？

---

感謝您的回覆。這個問題的目標是感受開發人員社區中最常用的工具，但似乎遷移並不是這裏的熱門話題。

無論如何，我已決定與MigSharp一起使用，因爲代碼庫看起來非常乾淨，而且它非常容易處理並且支持MS SQL CE。第二名亞軍將是FluentMigrator，因爲我無法爲緊湊版製作實例。

乾杯

Answer 1

我用FluentMigrator在生產，是一個長期的貢獻者FM。我認爲你的問題是一般的;更加詳細一些。另外，如果您想要FM信息，FM有一個相當活躍的Google組。

FM是從migrator.net派生的，我記得。它使用流利的語法，並支持多個數據庫。我們從軌道遷移中獲得了一些啓發，但它絕對不是港口。值得檢查。

我學到的一件事並不是將你的遷移與你的應用程序代碼放在同一個程序集中。將它們分成遷移程序集，然後使用它遷移數據庫。

另外，您應該始終在多個環境中工作，以避免遷移直接針對生產發生問題。我總是至少有一個開發和生產環境，大多數情況下還有一個測試環境。

Answer 2

我使用mig＃。

它運行良好，但您需要有一些使用指南 - 因爲遷移可能會變得複雜。

我們在遷移結束時使用序列號而不是日期時間戳。這是因爲我們不知道什麼時候設置了日期時間戳（當他們開始源代碼更改集時;就在提交之前;有時間），不同的開發人員可以使用不同的方法。

Migration_0000034.cs等名稱爲您提供了充足的空間。

Answer 3

在這一點上，我會堅持migrator.net。我喜歡FluentMigrator的承諾，但它似乎沒有比migrator.net更好的活動開發（請參閱在github網站上已經枯竭的問題和請求）。

執行ExecuteScalar（）也沒有簡單的方法。我會添加它，但我不想創建自己的分支，並且我沒有理由認爲拉請求實際上會落入主分支。 （Execute.WithConnection是一個動作，所以它會根據需要觸發，而不是在需要時觸發）

因此，對於我來說，我將返回到migrator.net。