傳統上我總是手工編寫我的sql腳本,所以他們很好,很乾淨(我不是生成者的粉絲)併發布發佈,我提供了新的安裝腳本和以前版本的遷移腳本,創建新的表格,改變現有的表格等等。這是非常標準的。EF 4代碼如何首先處理生產環境中的模式更改?
我並沒有真正有足夠的時間來使用EF 4代碼,但如果它在生產環境中真正可行,我很有興趣使用它。
假設你有一個代碼優先的方法,如果一個數據庫不存在,數據庫將自動創建。如果您發佈具有架構/模型更改的新版軟件,會發生什麼情況。 EF足夠聰明地更新數據庫模式以匹配更新的EF模型嗎?
方案
- 客戶端安裝的服務器上的asp.net MVC的網站。在第一次運行時,將創建一個新的數據庫
- 客戶端使用的網站了一段時間,在數據庫中獲取一些數據
- 同時該網站的一個新版本發佈和EF模式發生了變化
- 客戶端下載新的填充版本,部署網站,指向現有的數據庫
是代碼首先只對初始部署有用呢,還是足夠聰明來更新現有的數據庫版本而這樣嗎?
很好的瞭解,但直到特點是在野外,我不認爲這是我可以在辦公室倡導的路線。 – 2010-11-18 03:58:33
是的,我不確定EF 4框架是否足夠成熟來處理這個問題。感謝您的鏈接。我會暫緩這個功能,並在2011年初監控EF團隊的更新。乾杯! – 2010-11-18 04:16:52
@confusedGeek:即使在發佈此功能後,我相信沒有企業會將他們的生產數據庫提供給EF來爲他們即時修復。 alter script始終必須通過DBA,無論是由您還是由EF編寫。 – 2010-11-18 04:42:20