实体框架或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的生成工具。