C# 实体框架还是SQL Server Management Studio？

使用域驱动设计时，最好是采取微小的步骤（更改设计或代码、单元测试…）

我认为SQLServerManagementStudio提供的SQLServer很好（使脚本=编写代码），但是在我们测试设计之后，使用DDD在最后编写数据库代码

使用c#编写的代码，然后使用EF创建数据库，您将经常更改c#代码，这会隐式地更改数据库代码

---

如何最好地继续？

DDD鼓吹不知道持久性，这表明您的域工件（实体类、值对象）应该不知道它们是如何持久化的。然而，技术持久性问题并不总是容易避免或延迟的。因此，代码中的模型通常会受到持久性技术约束的影响

你已经预示了最好的方法：小步走。问题是什么构成了一个步骤。最初的步骤可以包括在代码中设计模型，然后实现持久性。随后的步骤重复该过程。事实上，这些步骤很小，这降低了您在代码中创建设计的可能性，而这些代码在优先关注模型而不是数据库的同时无法轻松持久化

---

关于SQLManagementStudio与EF生成器的使用，这是一个优先考虑的问题。我更喜欢手工编写SQL代码，其他人可能会喜欢EF的生成功能。

假设您正在从事棕地项目。然后，对于给定的用户故事：

1） 设计和单元测试您的域模型

2） 然后是您的基础架构。这包括针对为这些测试动态创建的数据库（可以在内存中或嵌入）测试存储库实现。NHibernate自动为您生成模式，但不确定EF。 对于持久性不可知无疑会有所帮助，因为您可以对SQLite进行测试，但可以对SQL Server进行测试

3） 然后是生产数据库的迁移脚本。没有什么黑魔法能帮你完成这一步。该脚本稍后可以由类似的框架执行。更多信息

---

冲洗并重复。对于尚未部署的绿地项目，您可以跳过步骤3）并在第一次生产部署时生成“基线”脚本。

好的，这是一个偏好问题，但EF的性能如何？它接近sql代码性能？如果进行最大程度的调整，您通常可以从原始sql中获得更好的性能，但是如果有合适的索引，并且查询不涉及复杂的连接，EF的性能就足够好了。