c# - 在 ASP.NET Core MVC 中使用 ORM 的正确方法？

Question

关闭。这个问题需要更多 focused .它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post .

4年前关闭。




Improve this question




一个缺乏经验的 Web 开发人员急需帮助!

简介

我正在开发一个 MVC Web 应用程序(由于我对它的兴趣而使用 ASP.NET Core)。
在后端，有一个带有相当复杂的数据库(数千个表)的 MSSQL 服务器。
在我的项目中，我想根据用户的查询(发送表单请求)在 View 中(在表格中)显示部分公共(public)数据，然后允许用户下载数据(CSV、XML)。

架构挑战

数据访问层

首先我开始使用 Entity Framework ，但后来意识到根本无法将我所有的 SQL 语句转换为 LINQ。原因是最简单的查询包含多个 INNER JOINS 和 LEFT JOINS 和 SELECT 语句以及无数个表。

业务逻辑层

我计划构建一个 REST API，以 JSON 格式发送数据。就我在 .NET Core MVC 中的关注而言，我可以将我的 API Controller 与我的表示层放在同一个项目中。

表示层

这是我唯一有经验的部分，使用 MVC 5 构建 Web 应用程序。

大斗争

在这个项目中，我不会操作数据，只会阅读并呈现给用户。我知道使用不同模型类(域、实体、 View 模型)的准则

我现在所做的，我想这是错误的:

MVC 的 API Controller 将 SQL 查询结果作为类型 DataTable 对象返回(有一个 SQL Helper 类来完成这项工作)，到目前为止，我的 Controller 负责将对象序列化为 JSON。

另一个 Controller (与 View 中的模型绑定(bind))通过 HTML 表单获取用户搜索条件，并通过绑定(bind)相应的属性调用 API Controller 。

终于有问题了

我是否应该坚持使用原始 SQL 查询而不是 Entity Framework ，如果是这样，我是否应该使用简单分离的类库(作为数据访问层)并在 API 中引用它？还是省略 DAL 并将所有 SQL 查询逻辑放入 API 中？

是否需要使用 Entity Framework 以防只阅读
不操纵数据？我打算做的唯一操作是在逻辑层中格式化外观。

更新编辑:

在我的 SQL 查询中，我必须创建 LINQ 不支持的临时表。有什么建议？

如果这个问题将被标记为架构问题而不是编程问题，请接受我的歉意，并将我推荐给我可以获得帮助的正确论坛。

提前谢谢了!

Answer 1

您会发现 LINQ 查询比 SQL 更容易理解和调试。将数据访问层作为一个单独的项目，并对查询进行单元测试。为了保持 SOLID 原则，不要将数据层与 api 混合。如果您刚刚开始，EF Core 可能比 EF6 更好，主要是因为速度和可移植性。