EF6和Onion架构 - 首先是数据库，没有Repository模式 [英] EF6 and Onion architecture - database first and without Repository pattern

问题描述

我正在把它放在一起，用于现有应用程序的新架构。现有的应用程序有很多业务逻辑，所以我认为洋面架构（或类似的东西 - 分层，去耦）可能是正确的解决方案 - http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

I'm trying to put it all together for an new architecture for existing application. Existing application has a lot of business logic, so I thought that Onion architecture (or something like that - layered, decoupled) could be the right solution - http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

我看到的所有示例都使用了基础架构层（或DAL，或任何实际连接到数据库的层）上的Repo / UoW（顶层或ORM）模式。但我不知道在我的情况下，需要购买Repo / UoW（在EF之上），因为：

All examples that I have seen use Repo/UoW (on top or ORM) pattern in Infrastructure layer (or DAL, or whatever the layer that actually connects to database is called). But I'm not sure that in my case Repo/UoW (on top of EF) is necessary, because:

• EF6可以很好地单元测试没有Repo模式，实现这样的Bounded DbContexts - http：// msdn.microsoft.com/en-us/library/dn314429.aspx

大多数Generic Repo示例倾向于使用漏洞抽象，因为它们暴露接受LINQ查询的方法（如表达式>查询）

Most Generic Repo examples tend to use leaky abstractions, because they expose methods that accept LINQ queries (like Expression> query)

所以这里有几个问题：

1）大多数示例在Core层中使用EF代码和POCO对象，但是我有首先使用数据库并生成模型。可以在Core中使用EF生成的.edmx模型，还是使数据访问成为不必要的耦合？有没有办法从EF生成的数据访问代码（context.tt文件等）分割EF生成的类（.cs文件与表字段）？

1) Most examples use EF code first and POCO objects in Core layer, but I have to use database first and generate model. Can I use EF generated .edmx model in Core, or does this makes unnecessary coupling to data access? Is there a way to split EF generated classes (.cs files with Table fields) from EF generated data access code (context.tt files etc.)?

2）我'计划实施这样的服务层（有限的DbContext接口作为依赖性传递）

2) I'm planning to implement Service layer like this (with Bounded DbContext interfaces being passed as dependencies)

public class OrderService(IMyDbContext) { ... } 

这意味着，而不是存储库接口，将有DbSets的DbContext包装器接口。单元测试可以通过模拟IMyDbContext和模拟IDataSet来完成。
这不是打败数据库抽象的整个概念吗？对我来说，这对于单元测试来说足够了，但从建筑的角度来看，这是否可以？我缺少一些伟大的功能，在这里提供Repo / UoW（在EF之上）模式？

This means, that instead of Repository Interfaces, there will be DbContext wrapper interfaces with DbSets. Unit testing could be done with mock IMyDbContext and mock IDataSet. Doesn't this beat the whole concept of abstracting away the database? Seems to me that this is enough for unit testing, but is this ok from architectural standpoint? Am I missing some great feature that Repo/UoW (on top of EF) pattern provides here?

3）似乎存储库的一个替代方案（虽然不是很受欢迎）是查询对象：
http://www.wekeroad.com/2014/03/04/repositories-and-unitofwork-are-not-a-good-idea/

3) Seems that one alternative for Repositories (although, not very popular) are Query Objects: http://www.wekeroad.com/2014/03/04/repositories-and-unitofwork-are-not-a-good-idea/

http://lostechies.com/jimmybogard / 2012/10/08 / favor-query-objects-over-repositories /

但是我没有真正发现有洋葱+查询对象的例子。这可能是Repository界面层的合理选择？在其中放置查询界面，并在接口（数据访问）层中查询实现？我应该将所有数据访问逻辑放在QueryObjects中吗？如果我直接在Coltroller / Service层中使用DbContext.Where查询，这是否会在Data Access和Business Logic之间产生不必要的联系？

But I haven't really found any examples with Onion + Query Objects. Could this be reasonable choice for Repository interface layer? Placing Query interfaces there instead, and Query Implementations in Interface (Data Access) layer? Should I place all data access logic inside QueryObjects? If I use DbContext.Where queries directly in Coltroller/Service layer, does this create unnecessary coupling between Data Access and Business Logic?

推荐答案

@andree

我有几个意见可能会增加这个讨论。我很欣赏这是一个较旧的线程，但我认为讨论仍然是有价值的。

I have a few comments that may add to this discussion. I appreciate this is an older thread but I think the discussion is still valuable.

首先，我现在建议不要使用EDMX文件，因为所有未来的EF7讨论似乎表明EDMX将被删除。
相反，从EF6.1开始，您可以从现有数据库中生成代码优先样式配置。

Firstly, I would now recommend not going with EDMX files as all the future discussions for EF7 seem to indicate that EDMX will be dropped. Instead, from EF6.1 you can now generate a "code-first" style configuration from an existing database.

代码优先应该是重命名为流畅配置

"Code-first" should probably be renamed to "fluent configuration"

大多数Generic Repo示例倾向于使用漏洞抽象，因为它们公开接受LINQ>查询的方法（如表达式>查询）

Most Generic Repo examples tend to use leaky abstractions, because they expose methods that accept LINQ >queries (like Expression> query)

非泛型Repos往往会导致大量代码

Non-generic Repos tend to cause a lot of code

<我通常发现，做一点点泄漏可能是有用的。我们使用共享IQueryable的存储库，以便编写快速查询很容易 - 但是常用的任何东西都可以转入存储库。显然，这将使得更难以用不能给你IQueryable的其他东西来替换持久化层，但实际上从来没有发生过。

I've generally found that it can be useful to be a little "leaky". We use repositories that share IQueryable so that it's easy to write quick queries - but anything that's used often get moved into the repository proper. Obviously this would make it harder to swap out the persistence layer with something else that can't give you IQueryable but in practice this has never happened to me.

我的方法非泛型Repos往往会导致很多代码问题一直是使用.tt模板生成代码。
- tt模板生成一堆部分存储库实现和接口。
- 然后，在你自己的部分文件中添加自己的方法。

My approach to the "Non-generic Repos tend to cause a lot of code" problem has been to use code generation with .tt templates. - tt templates generate a bunch of partial repository implementations and interfaces. - Then, add your own methods to this in your own partial files.

请看看这个图书馆：_
http://www.sswdataonion.com


（免责声明：我是开发人员之一）
它包含用于生成存储库和工作单元模式的tt模板。

please take a look at this library:
http://www.sswdataonion.com
(disclaimer: I was one of the developers for this)
It contains tt templates to generate a repository and unit-of-work pattern.

个人而言，如果我要写一个真正不可知的不泄漏服务层，我可能会把它写成一个存储库/工作单位之上的层模式。

Personally, If I was to write a truly agnostic "non-leaky" service layer I would probably just write it as a layer on top of a repository / Unit of work pattern.

这篇关于EF6和Onion架构 - 首先是数据库，没有Repository模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！