entity-framework - Entity Framework 6 数据库优先和洋葱架构

Question

我首先使用 Entity Framework 6 数据库。我正在转换项目以实现洋葱架构，以实现更好的关注点分离。我阅读了许多文章并观看了许多视频，但在决定我的解决方案结构时遇到了一些问题。

我有 4 个项目:核心、基础设施、Web 和测试。

据我所知，.edmx 文件应该放在我的“基础设施”文件夹下。但是，我还阅读了有关使用存储库和工作单元模式来协助 EF 解耦和使用依赖注入(inject)的信息。

话虽如此:

我是否必须在 CORE 下为模型中的所有实体创建存储库接口(interface)？如果是这样，如何在一个巨大的数据库上维护它？我研究了 automapper，但发现它在呈现 IEnumererables 与 IQueryables 时存在问题，但有一个可用的扩展程序可以解决这个问题。我可以更深入地尝试这条路线，但想先收到回复。

作为替代方案，我是否应该将我的 edmx 留在 Infrastructure 中并将我的实体的 .tt T4 文件移动到 CORE？这是否提供了任何紧密耦合或一个好的解决方案？

通用存储库接口(interface)是否可以很好地配合您提供的建议？或者，也许 EF6 已经解决了存储库和 UoW 模式问题？

感谢您查看我的问题，并请提供任何替代答复。

我在这里找到了一个类似的帖子，但没有得到回答:
EF6 and Onion architecture - database first and without Repository pattern

Answer 1

数据库优先并不能完全排除洋葱架构(又名端口和适配器或六边形架构，所以如果您看到对它们的引用，它们是相同的)，但这肯定更难。洋葱架构和它允许的关注点分离非常适合领域驱动的设计(我想你在推特上提到你已经看到了some of my videos on this subject on Pluralsight)。

您绝对应该避免将 EDMX 放在核心或 Web 项目中 - 基础设施是这样做的正确位置。那时，使用数据库优先，您将在基础架构中拥有 EF 实体。不过，您希望您的业务对象/域实体存在于 Core 中。那时，如果您想继续沿着这条路走下去，基本上有两种选择:

1)从数据库优先切换到代码优先(可能使用工具)，以便您可以在 Core 中拥有 POCO 实体。

2) 在基础设施实体和核心对象之间来回映射，可能使用 AutoMapper 之类的东西。在 EF 支持 POCO 实体之前，这是我使用它时遵循的方法，我将编写仅处理 Core 对象但在内部将映射到 EF 特定实体的存储库。

至于您关于存储库和工作单元的问题，已经在 SO 和其他地方写了很多关于此的文章。您当然可以使用通用存储库实现来允许对大量实体进行轻松的 CRUD 访问，这听起来可能是您在场景中前进的一种快速方法。但是，我的一般建议是避免将通用存储库作为访问业务对象的首选方式，而是使用聚合(请参阅 DDD 或我在 Pluralsight 上与 Julie Lerman 合作的 DDD 类(class))，每个聚合根都有一个具体的存储库。您也可以将复杂的业务实体从 CRUD 操作中分离出来，并且只在需要的地方遵循聚合方法。您从这种方法中获得的好处是您限制了访问对象的方式，并且在您的(大型)数据库实体集上获得了与 Facade 类似的好处。

不要觉得每个应用程序只能有一个 dbcontext。听起来您正在随着时间的推移不断发展这种设计，而不是从绿色应用程序开始。为此，您可以保留 .edmx 文件，也许还有一个通用存储库用于 CRUD 目的，然后为一组特定的操作创建一个新的代码优先 dbcontext，这些操作保证 POCO 实体、关注点分离、提高可测试性等。随着时间的推移，您可以转移大部分基本代码来使用它，同时仍然保留现有的 dbcontext，这样您就不会丢失当前的功能。