14

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

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

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

话虽如此：

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

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

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

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

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

4

2 回答 2

10

数据库优先并不能完全排除洋葱架构（又名端口和适配器或六边形架构，所以如果您看到对它们的引用，它们是相同的），但这肯定更难。洋葱架构和它允许的关注点分离非常适合领域驱动的设计（我想你在推特上提到你已经在 Pluralsight 上看过我关于这个主题的一些视频）。

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

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

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

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

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

于 2014-06-24T20:39:45.303 回答
1

我在我的 DDD 项目中使用实体框架 6.1。如果你想做洋葱架构，代码优先效果很好。

在我的项目中，我们将存储库与域模型完全隔离。应用程序服务是使用存储库从数据库加载聚合并将聚合持久保存到数据库的东西。因此，域（核心）中没有存储库接口。

使用 T4 在单独的程序集中生成 POCO 的第二种选择是一个好主意。请记住，您的域模型（核心）应该是持久性无知的。

虽然通用存储库有利于执行聚合级操作，但我更喜欢使用特定存储库，因为并非每个聚合都需要所有这些通用存储库操作。

http://codingcraft.wordpress.com/

于 2014-08-24T04:38:21.663 回答