我首先使用Entity Framework 6数据库。我正在转换该项目以实施洋葱架构，以便更好地分离关注点。我阅读了很多文章并观看了很多视频，但在决定我的解决方案结构时遇到了一些问题。
我有4个项目：核心，基础设施，网络和测试
根据我所学到的，.edmx文件应放在我的基础设施＆＃34;夹。但是，我还阅读了有关使用Repository和Unit of Work模式来帮助EF解耦和使用依赖注入的信息。
据说：
我是否必须在CORE下为模型中的所有实体创建存储库接口？如果是这样，如何在庞大的数据库中维护这个？我已经研究过自动播放器，但发现了IEnumererables与IQueryables的问题，但是有一个扩展可用它必须与此一起发布。我可以更深入地尝试这条路线但是想先听一听。
作为替代方案，我应该将我的edmx留在基础架构中并将我的实体的.tt T4文件移动到CORE吗？这是否存在紧密耦合或良好的解决方案？
通用存储库界面是否适用于您提供的建议？或者EF6已经解决了Repository和UoW模式问题？
感谢您查看我的问题，并提出任何其他回复。
我在这里找到了类似的帖子，但没有回答： EF6 and Onion architecture - database first and without Repository pattern
答案 0 :(得分：8)
数据库首先没有完全排除Onion架构（也就是端口和适配器或六边形架构，所以如果你看到那些它们是同一个东西的引用），但它肯定更难。洋葱架构和关注点的分离，它可以很好地适应域驱动的设计（我想你在Twitter上提到过你已经看过some of my videos on this subject on Pluralsight）。
你绝对应该避免将EDMX放入Core或Web项目中 - 基础设施是适合它的地方。此时，使用数据库优先，您将在基础架构中拥有EF实体。但是，您希望业务对象/域实体存在于Core中。此时，如果您想继续沿着这条路走下去，基本上有两个选择：
1）首先从数据库切换到代码（可能使用工具），以便在Core中拥有POCO实体。
2）在您的Infrastructure实体和Core对象之间来回映射，可能使用类似AutoMapper的东西。在EF支持的POCO实体之前，这是我在使用它时所遵循的方法，我会编写仅处理Core对象但内部将映射到EF特定实体的存储库。
至于你关于存储库和工作单元的问题，在SO和其他地方已经有很多关于这方面的问题。您当然可以使用通用存储库实现来轻松访问大量实体的CRUD，听起来这可能是您在场景中前进的快捷方式。但是，我的一般建议是避免使用通用存储库作为访问业务对象的首选方法，而是使用Aggregates（参见DDD或我在DDrals上的Julie Lerman的DDD课程）和每个Aggregate Root的一个具体存储库。您也可以将复杂的业务实体从CRUD操作中分离出来，并且只在遵循保证的情况下遵循聚合方法。您从这种方法中获得的好处是，您正在约束对象的访问方式，并通过您的（大型）数据库实体集获得与Facade类似的好处。
不要觉得每个应用程序只能有一个dbcontext。听起来你随着时间的推移不断改进这个设计，而不是从绿色领域应用开始。为此，您可以保留.edmx文件，也许还有CRUD用途的通用存储库，但随后为一组特定的操作创建一个新代码dbcontext，这些操作可以保证POCO实体，关注点分离，可测试性增加等。随着时间的推移，你可以转移大量的基本代码来使用它，同时仍然保留现有的dbcontext，这样你就不会丢失和当前的功能。
答案 1 :(得分：1)
我在我的DDD项目中使用实体框架6.1。如果你想做洋葱建筑，代码首先很好。
在我的项目中，我们从域模型中完全隔离了存储库。 Application Service是使用存储库从聚合中加载聚合并将聚合持久保存到数据库的内容。因此，域（核心）中没有存储库接口。
使用T4在单独的程序集中生成POCO的第二个选项是个好主意。请记住，您的域模型（核心）应该是持久性无知的。
虽然通用存储库适用于强制执行聚合级操作，但我更喜欢使用特定存储库，因为不是每个聚合都需要所有这些generic repository operations。