EFCorePowerTools：从写模型DbContext生成读模型DbContext的探索

在领域驱动设计(DDD)实践中，我们通常会区分命令流(写操作)和查询流(读操作)的数据访问需求。命令流关注领域模型的完整性，而查询流则更注重查询效率和便捷性。本文将探讨如何利用EFCorePowerTools工具从写模型DbContext自动生成适合查询的读模型DbContext。

背景与挑战

在典型的DDD架构中，写模型DbContext通常设计为：

• 仅通过聚合根ID加载完整聚合
• 不暴露过多查询能力
• 包含丰富的领域行为

而读模型DbContext则需要：

• 包含导航属性的完整配置
• 支持灵活的Include和投影操作
• 返回简单的DTO而非领域对象

传统做法需要先通过写模型的迁移创建数据库，再反向工程生成读模型DbContext。这个过程不仅繁琐，而且容易在模型变更时产生不一致。

解决方案探索

对于SQL Server/Azure SQL数据库，可以尝试以下自动化流程：

1. 生成SQL创建脚本：使用EF Core CLI从写模型DbContext生成数据库创建脚本
2. 创建.dacpac文件：使用sqlpackage工具将SQL脚本转换为.dacpac格式
3. 生成读模型DbContext：使用EFCorePowerTools CLI从.dacpac文件反向工程生成新的DbContext

对于PostgreSQL等非SQL Server数据库，流程略有不同：

1. 同样先生成SQL创建脚本
2. 将脚本应用到实际数据库
3. 再从数据库反向工程生成读模型DbContext

注意事项

1. 不同数据库提供程序可能生成略有不同的模型
2. 自动化流程可能无法完全替代手动调整
3. 模型变更时需要同步更新读模型生成流程

最佳实践建议

1. 考虑将读模型生成流程纳入CI/CD管道
2. 为读模型DbContext使用独立的命名空间
3. 定期验证读写模型之间的一致性
4. 对于复杂场景，考虑真正的CQRS分离

通过这种半自动化的方式，可以在保持DDD原则的同时，提高查询效率并减少手动维护成本。虽然EFCorePowerTools并非专为此场景设计，但它提供的反向工程能力可以很好地支持这种"轻量级CQRS"实现方式。