實體框架或SQL Server Management Studio？

Question

使用領域驅動的設計最好是做出微小的步驟（更改設計或代碼，單元測試...）。

1. 我認爲這是很好的（使腳本=編寫代碼），從SQL Server Management Studio中的SQL Server，但與DDD數據庫代碼在年底寫的，經過我們測試的設計。

2. 用c＃編寫的代碼，然後用EF創建數據庫，你會經常更改c＃代碼，這會隱含地改變數據庫代碼。

如何繼續？

Answer 1

假設你正在做一個棕地項目。然後對於給定的用戶故事：

1）設計和單元測試您的域模型。

2）然後integration-test您的基礎設施。這包括針對爲這些測試動態創建的數據庫測試存儲庫實現（可以在內存中或嵌入式）。 NHibernate自動生成架構，不確定EF。 持久性不確定性在這裏肯定會有幫助，因爲您可以針對SQLite進行測試，但是可以針對SQL Server運行。

3）Then manually write遷移腳本爲您的生產數據庫。沒有什麼黑魔法可以幫助你完成這一步。該腳本稍後可以由像RoundhousE這樣的框架執行。更多信息here。

沖洗並重復。對於尚未部署的綠色領域項目，您可以跳過步驟3），並在第一次生產部署時生成「基準」腳本。

Answer 2

DDD鼓吹持久性的無知，它表明你的域工件（實體類，值對象）應該不知道它們是如何被持久化的。但是，技術上的持久性問題並不總是可以輕易避免或延遲的。因此，代碼中的模型通常會受到持久性技術約束的影響。

你已經預示了最好的方法：微小的步驟。問題是什麼構成了一個步驟。初始步驟可以包括在代碼中設計模型，然後實現持久性。隨後的步驟重複該過程。這些步驟很小的事實減少了您在代碼中創建設計的機會，這些代碼不能輕易地全部保留，同時優先考慮將重點放在數據庫上的模型上。

關於SQL Management Studio與EF生成器的使用，這是一個偏好問題。我更喜歡手寫SQL代碼，其他人可能會喜歡EF的生成工具。