该架构的名称是什么以及在服务而不是控制器中使用 dbcontext 的目的是什么？
我有多个具有get/post函数的API控制器，需要数据库访问（读/写）。因此，我创建了dbContext，并通过构造器注入将其注入每个控制器。然后在get/post函数中，我使用实体框架查询语法，例如：
_context.TableName.Where...Select...ToListAsync()
我被要求对此进行审查，而不是注入dbcontext，而是从它并将服务注入控制器。
我是否正确理解这意味着该服务将具有功能（例如getData（），insertdata（val）（val））。在此服务中，功能将是与数据库进行交互的实体框架查询。然后，我必须将服务注入控制器中，以便当功能get/post需要与他们使用服务功能的数据库进行交互。我相信这是将实体框架查询语法分开的，并将其放入服务类而不是控制器。
这样的架构叫什么？
I have multiple API controllers that have GET/POST functions which require database access (read/write). So I have created the dbcontext and injected it into every controller via constructor injection. Then within the GET/POST functions, I am using Entity Framework querying syntax like:
_context.TableName.Where...Select...ToListAsync()
I have been asked to review this and rather than injecting the dbcontext, make a service out of it and inject the service into the controller.
Am I correct to understand that this means the service will have functions (like GetData(), InsertData(val)). Within this service functions will be the entity framework querying that is interacting with the database. I must then inject the service into the controller so that when the functions GET/POST want to interact with the database they make use of the service functions. I believe this is so as to separate the Entity Framework query syntax and place it into service class rather than the controller.
What is such an architecture called?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
它称为存储库模式/分层体系结构。
Its called repository pattern/layered architecture.
它称为存储库模式，通过在服务/存储库中提取数据库逻辑，您可以使其更可读。
理想情况下，您的API层仅应担心以下几点
数据库或业务逻辑应在单独的层中，此层处理所有业务逻辑和数据库访问。
如果您想更深入研究，您也可以将业务层和数据库层分开，因此您的API会将请求转发到业务层，并且业务层将执行所需的业务逻辑，因为数据库访问业务逻辑会将数据库层调用数据库层以获取数据。 这种方法的主要优点是，如果要更改数据库提供商，您只需要修改数据库层，此方法称为 3层架构。
**编辑**
在这里使用.NET 5 API和ANGULAR 12带SQL Server
It is called Repository pattern, by extracting database logic in service/repository you are making it more readable.
Ideally you api layer should only worry about following points
Database or business logic should be in separate layer, this layer handles all business logic and database access.
If you want to go deeper you could also separate business layer and database layer too, So your api will forward request to Business layer and business layer will perform required business logic, for database access Business logic will call Database layer for data. Main advantage of this approach is that if you want to change database provider you will only need to modify Database layer, this approach is called 3 Layer architecture.
** EDIT **
Here is example web app with .net 5 Api and angular 12 with Sql server
“分层架构”将业务层和数据库层与表示层分开，也称为n层架构。
最常见的 3 层架构；
https://www.oreilly.com/library/ view/software-architecture-patterns/9781491971437/ch01.html
你什么称呼这3层似乎差别很大！
但简而言之，
* 只是意味着还有更多内容
"layered architecture" separate business layer and database layer from presentation also known as n-tier architecture.
Most commonly 3 Layer architecture;
https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html
What you call these 3 layers seems to vary a lot!
but in a nutshell
the * just means there's more to the story