实体框架VS纯Ado.Net

本文关键字：Ado Net VS 框架 实体 | 更新日期: 2023-09-27 17:49:27

EF是如此广泛使用的员工，但我不知道我应该如何使用它。我在英孚不同的项目中遇到了很多问题，方法也不同。所以一些问题在我脑海中浮现。答案使我使用纯ado.net与存储过程。

问题是:

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

    • 重新映射EF负载会导致一些DTO降低性能(调用一些select来获取表数据-第一个循环，第二个循环-将结果映射到EF生成的某些复合类型，下一步-使用linq过滤映射的数据，最后将其映射到某些DTO)。准确地重新映射到DTO是efs最大的好处之一;
      或
    • 导致EF(和它的版本)和应用程序之间的强内聚。它将类似于带有dal和带有bll的演示的2层应用程序或带有bll和演示的dal。我想这不是最好的做法。加载过程和之前一样除了映射，性能问题又出现了。我们可以尝试使用EF作为DAL，而不需要在它们下面进行任何抽象。但我们也会以其他方式遇到类似的问题。

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

  3. 我们可以尝试只使用EF +存储过程吗?我们还有之前问题的问题。如果大部分功能不会被使用，那么使用EF的原因是什么?

所以，是的，EF是伟大的开始项目。当我们有很少的屏幕和繁琐的操作时，它是如此的方便。

接下来呢?

所有这些文字都是杂乱无章的想法。我知道，纯ado.net将会带来另一种挑战。

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

实体框架VS纯Ado.Net

通过遵循命名约定，您将发现它被称为:ADO。. NET实体框架，这意味着实体框架位于ADO之上。它可以在相同的时间内完成这两个任务，但是让我们看看EF提供的:

  • 你将不再被写查询而没有任何线索，如果你写的是编译或不。
  • 它让你依靠c#或你最喜欢的。net语言来编写你自己的数据约束，你希望直接在你的模型类中接受来自目标用户的数据约束。

最后:EF和LINQ为以后维护应用程序提供了很多功能。

实体框架有三种不同的模型:模型第一，数据库第一和代码第一。

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

ADO。Net是一个面向对象的框架，允许您与数据库系统(SQL, Oracle等)进行交互。实体框架是一种操作数据库中数据的技术，例如(查询集合(惰性表名，select * from like this))。它与LINQ一起使用。

实体框架在任何情况下都不是高效的，因为大多数工具或工具箱都是为了实现"更快"的结果而设计的。

  1. 对数据库的访问应该被视为一个单独的层，使用存储过程作为接口。任何应用程序都没有理由拥有绝对需要的CRUD操作。少即是多原则。存储过程易于编写、安全、维护，而且实际上是最快的方法。通过存储过程编写工具来生成POCO和DbContext所需的代码是很容易的。

  2. 设计良好的应用程序应该有有限数量的连接字符串到数据库，其中没有一个应该是全能的上帝。使用模式来支持连接权限。

  3. 延迟加载是为了解决一个本不应该存在的问题而添加的错误语句，是ORM及其即插即用特性引入的。应该只在需要时读取数据。开发人员应该负责根据应用程序上下文实现此逻辑。

  4. 如果您的应用程序逻辑在维护状态方面存在问题，那么没有工具可以帮助您。事实上，掩盖真正的问题会使情况变得更糟，直到为时已晚。

  5. 数据库首先是设计良好的应用程序的唯一解决方案。人类文明在很久以前就认识到固体沟渠和下水道系统的重要性。高级代码可以随时被替换，但数据会保留下来。如果数据库设计得好，重写整个应用只需要几天的时间。

  6. 应用程序只是美化了的数据库访问。大多数情况下仍然是正确的。

这是我多年来通过许多不同工具或工具箱生成的代码调试业务应用程序后得出的结论。广告中所宣传的更快的结果甚至无法弥补之后试图清理混乱所浪费的时间和精力。性能问题很少是由高需求引起的，而是通过不可用的工具添加的所有"功能"的总和。

ADO。. NET提供对数据源(如SQL Server和XML)以及通过OLE DB和ODBC公开的数据源的一致访问。数据共享消费者应用程序可以使用ADO。. NET连接到这些数据源，并检索、处理和更新其中包含的数据。

Entity Framework 6 (EF6)是一个久经考验的。net对象关系映射器(O/RM)，经过多年的特性开发和稳定。像EF这样的ORM具有以下优点

  • ORM让开发人员专注于应用程序的业务逻辑，从而大大减少了代码。

  • 它消除了重复SQL代码的需要，并为开发速度提供了许多好处。

  • 防止编写手动SQL查询;,更多. .

  1. 在n层应用程序中，它取决于应用程序正在处理的数据量和数据库正在管理的数据量。据我所知，DTO不会影响性能。它们是用于在层之间移动数据的数据容器，仅用于传递数据，不包含任何业务逻辑。它们主要用于服务课程。看到DTO。
  2. 一个DBContext始终是最佳实践。
  3. 据我所知，EF + SP(存储过程)没有这样的组合。如果你想同时使用像EF和SP这样的ORM，可以尝试像Dapper、BLToolkit等这样的微ORM，它就是为此目的而构建的，比EF快得多。这里有一篇关于Dapper ORM的好文章

这里有一个类似主题的相关线程:表单和ADO.net之间的区别是什么?

相关文章：