c# - Entity Framework VS 纯 Ado.Net

Question

EF 是一个被广泛使用的人员，但我不知道我应该如何使用它。我在使用不同方法的不同项目中遇到了很多关于 EF 的问题。所以我脑子里汇集了一些问题。答案让我使用带有存储过程的纯 ado.net。

所以问题是:

1. n层应用如何处理EF？
   例如，我们有一些带有 EF 的 DAL。我看到很多文章和项目使用存储库、工作单元模式作为 EF 的某种抽象。我认为这种方法扼杀了提高开发速度的大部分好处，并导致了一些事情:

   • EF 负载的重新映射导致某些 DTO 会降低性能(调用一些选择以获取表数据 - 第一个循环，第二个循环 - 将结果映射到由 ef 生成的某些复合类型，接下来 - 使用 linq 过滤映射数据，最后，将其映射到某个 DTO)。准确地重新映射到 DTO 是最大的 efs 好处之一的 killer ；
     或
   • 导致 EF(及其版本)和应用程序之间的强大凝聚力。它将类似于带有 dal 和带有 bll 的演示文稿或带有 bll 和演示文稿的 dal 的 2 层应用程序。我想这不是最佳做法。除了映射之外，加载过程与之前的加载过程相同，因此性能问题再次出现。我们可以尝试将 EF 用作 DAL，而无需在它们下进行任何抽象。但是我们会以其他方式遇到类似的问题。

2. 我应该为每个应用\线程\原子操作使用一个上下文吗？使用方法 - 每个应用程序\线程一个上下文可能会略微提高性能和调用导航属性的可能性，但我们遇到另一个问题 - 更新此上下文并在上下文中增加加载的数据，我也不确定每个应用程序一个 dbcontext 的并发性\线。每个操作使用上下文将引导我们将 EF 结果重新映射到我们的 DTO。所以你看到我们再次推回问题 1。

3. 我们能否尝试仅使用 EF + 存储过程？我们再次遇到以前问题的问题。如果不会使用大部分功能，使用 EF 的原因是什么？

所以，是的，EF 非常适合启动项目。当我们只有很少的屏幕和粗略的操作时，它非常方便。

但是接下来呢？

所有这些文字只是未分类的想法。我知道纯粹的 ado.net 会带来另一种挑战。

那么，你对这个话题有什么看法？

Answer 1

按照命名约定，您会发现它叫做:ADO.NET Entity Framework，这意味着 Entity Framework 位于 ADO.NET 之上，所以它不能更快​​，它可能同时执行两者，但是让我们看看 EF 提供的:

• 您将不会再被编写查询所困，而不知道您所编写的内容是否会被编译。
• 它让您依赖 C# 或您最喜欢的 .NET 语言来编写您自己的数据约束，您希望直接在您的模型类中接受来自目标用户的数据约束。

最后:EF 和 LINQ 为以后维护您的应用程序提供了强大的功能。

Entity Framework 有三种不同的模型:模型优先、数据库优先和代码优先，了解它们中的每一个。

-关于在进程上进行重新映射时会降低性能的要点，这是因为在第一次运行时，EF 将元数据加载到内存中，这需要时间，因为它从 edmx 文件构建模型的内存中表示。