首先，使用实体框架代码抽象数据访问层

Question

我有两个单独的数据库。数据库A很小，包含6个表和一些存储的过程，数据库B较大，并且包含52个表，159个视图和一些存储过程。我的任务是创建一个在这两个数据库上进行操作的应用程序。已经编写了访问这些数据库的代码，但是这是不可测试的，我想从头开始创建DAL代码。因此，我建立了一个代码第一实体框架连接，并让它为我以及上下文类创建所有POCOS。现在我有3个DataBaseContext类。 1对于数据库A，仅是6个单独的表。 1对于数据库B的表和1的表，对于数据库B的视图。我将数据库B的上下文类分为两个单独的上下文类，因为表和视图在2个不同的方案中使用。

我已经在一个解决方案中创建了2个项目。 domainModel和dataAccesslayer。 DomainModel项目持有实体框架代码首先生成的所有POCO。 dataAccesslayer是DataBaseContexts所在的位置，也是我想创建其他项目可以用来访问数据库的代码的位置。我的目标是制作可重复使用的可重复测试数据访问层代码。

问题是：我在DataAccesslayer项目中如何创建什么，以使DAL在其他希望能够抽象的方式与数据库交谈的项目中可以解析，什么是构造它的最佳方法是什么？

我做了什么： 在我在Internet上的搜索中，我已经看到人们推荐存储库模式（有时使用Unitofwork），这似乎是可以进行的，因此我创建了一个称为IgenericRepository的界面和一个称为generentityframeworkerworkitory的实现。该接口具有诸如GetByID，插入，删除和更新之类的方法。实现将DBContext作为构造函数中的参数，并实现所有方法。下一步可能是为不同的表和视图创建特定的实现，但这将是一件非常乏味的事情，因为有很多表格和视图。 我还读到实体框架是DAL。然后，创建另一个拥有业务逻辑并返回Ienumerables的项目可能就足够了。但这似乎很难测试。

我正在尝试实现的是一个结构良好且可测试的基础，可以访问我们的数据库，随着其他项目开始需要数据库的其他功能，可以进行彻底测试并扩展。

该项目的文件夹结构可以在以下图片中看到：

Answer 1

设计和架构都是关于权衡的。要考虑为重用目的抽象数据访问时，请小心。在应用程序中，这会导致过度复杂且性能不佳的解决方案，可以是一个非常简单且快速的解决方案。

例如，如果我想构建一个业务域层作为一组服务集，该服务将被许多不同的应用程序（将为移动应用程序或第三方兴趣的Web应用程序和服务/API）消费这定义了将会输入哪些信息，以及将出现哪些信息。进出该抽象的所有内容都应该是反映我通过我提供的操作提供的域的DTO。在该边界内，应利用EF来执行产生相关DTO或基于传递的具体详细信息更新实体所需的投影。（经过验证后）权衡取舍，每个消费者都需要与此通用相关访问点，因此，除非您构建它，否则几乎没有自定义的空间来自定义发生的东西。这比让所有事情都可以访问数据库并运行自定义查询或调用存储过程。这是可取的。

我最经常看到的是，在单个解决方案中，开发人员希望抽象系统不“知道”数据域是由EF提供​​的。该应用程序通过POCO实体或DTO进行通过，并且它们实现了使用GetByID，Getall，Update，UpSert等的通用存储库等的事情。这是一个非常非常非常糟糕的设计决定，因为这意味着您的数据域无法利用诸如投影，投影，，分页，自定义过滤，订购，急切的加载相关数据等。抽象EF DBContext无疑是启用单元测试的有效目标，但我强烈建议您避免使用通用存储库模式的性能陷阱。 IMO只是为了隐藏或使其可交换而试图抽象EF是表现不佳和/或过于复杂的混乱。

以典型的getall（）方法为例。

public IEnumerable<T> GetAll()
{
    return _context.Set<T>().ToList();
}

如果您只想过去三个月的订单，会发生什么？

var orders = orderRepository.GetAll()
    .Where(x => x.OrderDate >= startDate).ToList();

这里的问题是getall（）将始终返回所有行。如果您有400万个订单，您可以欣赏这是不可取的。

您可以制作一个订单重新设备，该订单将扩展存储库来实现诸如getordersfter（dateTime）之类的方法，但是很快，通用存储库的重点是什么？下一个选项是传递 expression＆lt; func＆lt; tentity＆gt;＆gt; ，其中sar in the getall（）方法。那里有很多例子。但是，这样做是将泄漏到消费代码中。其中的子句表达式必须符合EF规则。例如通过 order =＆gt; order.someunmapperproperty == someValue 将导致查询失败，因为EF无法将其转换为SQL。即使您对getall方法也需要开始看起来像：

IEnumerable<TEntity> GetAll(Expression<Func<TEntity>> whereClause = null, 
    IEnumerable<OrderByClause> orderByClauses = null, 
    IEnumerable<string> includes = null, 
    int? pageNumber = null, int? pageSize = null )

或某些类似的怪兽来处理过滤，订购，急切的加载和分页，这甚至无法涵盖投影。为此，您最终会采用其他方法，例如：

IEnumerable<TEntity, TDTO> GetAll(Expression<Func<TEntity>> whereClause = null, 
    IEnumerable<OrderByClause> orderByClauses = null, 
    IEnumerable<string> includes = null, 
    int? pageNumber = null, int? pageSize = null )

将调用另一个getall，然后执行映射器。映射以返回所需的DTO/ViewModel，希望在映射依赖项中注册。然后，您需要考虑 async 与该方法的同步口味。 （或强迫所有呼叫是同步的或 async ）

总的来说，我的建议是避免使用通用的存储库模式，而不只是为了抽象而抽象EF，而是寻找方法来利用最多的方法您可以摆脱它。开发人员的大多数问题都遇到了EF的性能和奇特的行为，源于使其抽象的努力。他们非常担心需要将其抽象为能够在需要的情况下取代它，以至于他们完全遇到了这些表现和复杂性问题，这完全是由于抽象施加的局限性。 （一个自我实现的预言）当您试图过早地优化解决您当前没有的问题的解决方案时，“体系结构”可能是一个肮脏的词，并且可能永远不会面对。始终保持Yagni并亲吻所有设计注意事项的最前沿。

Answer 2

我想您在为给定解决方案选择正确的架构之间跌倒。必须为满足业务需求而创建软件。因此，根据业务，域的复杂性，我们必须选择写架构。

Microsoft详细介绍了此处PDF，您会在这里找到它

您希望数据与BL随后的“ N层”体系结构之间的抽象水平并不是最好的解决方案。即使我没有告诉N层已经过时了，但是对于这个问题，还有更多合适的解决方案。

而且，如果您使用EF或EF Core，则无需实现存储库本身包含UOW和存储库。

干净的体系结构引入了层之间更高水平的抽象水平。它将您的数据层抽象化，并使其可以在不同的项目或不同的解决方案上重复使用。干净的体系结构是我在这里无法描述的一个大主题。但是我从他那里学到了这个话题。

Jason Taylor-清洁建筑

https://wwww.youtube.com/watch？v = dk4yb6 -lxak

https：//github.com/jasontaylordev/cleanarchitection