许多人认为EF已经实现了存储库模式，所以有抽象抽象没有意义....

但是，我很高兴我创建了自己的抽象。因此，人们可以很容易地从EF转换到另一个OR映射器 - 但我认为这是一个非常不可能的场景......但是一直发生的事情是有一个新版本的EF - 而不必改变依赖关系（到EF）在很多项目中都是一大利益。另外，为数据访问代码编写单元测试更容易（例如，通过注入In-Memory-Repository实现，不需要数据库或测试连接。



所以一般来说（主要是如果你使用生成的模型）在EF上创建自己的抽象是没有意义的。

在许多项目的非常大的解决方案中，依赖性管理是至关重要的（考虑一下创建设置等等。所以额外的抽象可以带来它的好处。（许多其他解决方案可能）



我会说：如果你看到一个真正的理由创建你自己的抽象，做吧。如果你现在没有 - 请遵循YAGNI原则!!!



亲切问候Johannes

Many argue that EF already implements Repository pattern, so there is no point in abstracting the abstraction....
But, I'm glad I created my own abstraction over it. So one could easily change from EF to another OR-mapper - but I think this is a quite unlikely scenario... But what happens all the time is that there is a new version of EF - and not having to change the dependency (to EF) in a lot of projects is a big benefit. Also writing unit-tests for the data-access code is easier (e.g. by injecting an In-Memory-Repository implementation, which doesn't need a database or -connection for Tests.

So in general (mostly if you use generated models) there is no Point in creating your own absraction over EF.
In very big solutions with many projects, dependency mmnagement is crucial (think about creating Setups and so on). So additional abstraction can have it's benefits. (many other solution possible)

I'd say: If you see a real reason to create your own abstratction, do it. If you don't have one now - follow the YAGNI prinicple!!!

Kind regards Johannes

Repository模式隐藏了如何存储/检索数据的细节。如果这样可以使您的代码更易于阅读和/或理解，那么它就是有用的。尝试阅读Repository模式的示例这里 [ ^ ]和这里 [ ^ ]

The Repository pattern hides the details of how the data is stored/retrieved. If that makes your code easier to read and/or understand then it is "useful". Try reading the examples of Repository pattern here [^] and here[^]