C# 直接将DB上下文注入服务层（没有存储库层）是一种好的做法吗？

我想让我的控制器尽可能干净，所以我想把所有的业务逻辑放在服务层中，在那里我想注入数据库上下文。值得澄清的是，我将使用EF Core

知道EF Core已经实现了存储库模式和工作单元。我会直接将DB上下文注入到我的服务中。我不想创建不必要的抽象，例如存储库层。

将DbContext注入服务层是一种常见的做法，但它本身并不是一种好的做法

我希望保持控制器尽可能干净，因此我希望将所有业务逻辑放在服务层中

这种说法可能是矛盾的，你想把所有东西都放在一个地方，你想让它尽可能干净。。。这是实现您自己的存储库背后的主要驱动因素

• Repository模式的一个关键目标是尝试并封装数据转换和查询逻辑，以便它可以重用并与数据库设计本身分离
• 工作单元关注跟踪更改，并协调如何以及何时将这些更改提交到数据库，可能是跨多个存储库提交

EF DbContext管理映射到数据库架构表的业务域实体存储库上的实现。因此，EF代表UOW和回购

EF何时是良好的回购？ 仅仅因为EF是一个Repo，并不意味着它是解决方案的Repo，EF可以是完美的Repo，因为业务域逻辑可以直接访问它，但是断开连接的服务架构可能会阻碍这一点，除非您的整个业务逻辑封装在服务层中，因此，客户端/UI中的每个按钮点击和决策点都会映射回API，然后一些业务逻辑会溢出到客户端，因此，如果要以有意义的方式公开客户端需要的所有功能，基于EF的服务层需要大量管道

如果您最终将所有或大部分EF模型类映射到DTO中，或者您想要向客户公开一个完全不同的业务模型，那么在API控制器类中执行所有这些操作很容易成为一个巨大的管理和维护问题，使用API控制器，您确实需要将请求和响应的路由和反序列化与实际逻辑分离，使用另一个Repo封装传输（控制器）的逻辑实现是一件好事，这通常意味着您不会注入DbContext，除非它只是简单地传递给该控制器的回购协议

如果EF模型没有被控制器公开，那么最好避免将DbContext注入控制器，因为它会鼓励您在控制器本身中做太多事情

让我们考虑一下将DbVice注入服务层是一个好的实践： 在具有服务层的分层解决方案中，如果EF模型表示将在服务和客户端之间传输的主要DTO，那么EF是直接在控制器中使用的一个好选择。事实上，如果这是您的目标，那么您应该把ODATA看作是一个服务框架，因为它提供了一个附加的抽象层（ODATA模型）。它最初映射到EF模型，但您可以轻松地扩展元素以实现自定义业务逻辑或结构，另外还可以公开基于约定的标准接口以查询来自客户端的数据

OData基本上将HTTP查询映射到延迟EF查询，而延迟EF查询又映射到SQL查询（或您选择的后端）。如果您使用简单或连接的OData客户端框架，那么客户端linq语句可以通过（尽管是间接的）数据库来执行

当您的EF模型表示从服务中公开并由客户端使用的大部分DTO时，将DbContext注入控制器定义是一种标准做法，OData是一种实现，它以最小的努力完成这一点，并提供客户端实现来管理客户端上的UOW

为什么我需要另一个抽象层 如上所述，由于事物的不连续性，服务层几乎总是形成自己的抽象层，无论您是否选择识别或实现它们，服务层都会对业务逻辑的调用施加安全性和结构约束。有时我们在服务端转换数据以提高效率或减少带宽，有时则故意隐藏或使用旧的机密数据或处理关键数据，或阻止客户更新某些字段

还有协议的问题，大多数现代API甚至添加了这样的服务，即客户机指定的不同格式可以使用该服务。你的控制器代码会变得非常繁重，我敢说，当你开始调整其中一些因素时，你会变得脏兮兮的

通过创建自己的repo来管理这些交互，将传输和绑定与业务逻辑分离，您可以获得很大的灵活性和互操作性

我不想创建不必要的抽象，比如存储库层

在一个小项目中，或者在一个非常小的团队中，这似乎是不必要的，但创建自己的回购协议的许多好处将在以后实现，无论是在聘用新的开发人员时，还是在将项目扩展到更多或新类型的客户时，或者更重要的是，当底层框架或操作系统发生变化时，您需要适应它们

在大多数情况下，另一个抽象层不应意味着引入了另一个性能瓶颈