EntityFramework VS纯Ado.Net

Question

EF是如此广泛使用的员工,但我没有意识到我应该如何使用它.我用不同的方法在不同的项目上遇到了很多关于ef的问题.所以有些问题汇集在我脑海里.并且答案使我使用纯ado.net和存储过程.所以问题是:

1. 如何在n层应用程序中处理EF？例如,我们有一些带有EF的DAL.我看到很多文章和项目使用存储库,单元工作模式作为EF的某种抽象.我认为这种方法会杀死大多数可以提高开发速度并导致一些事情的好处:
   • 重新映射EF负载会导致某些DTO杀死性能(调用一些select来获取表数据 - 第一个循环,第二个循环 - 将结果映射到ef生成的某些复合类型,next - 使用linq过滤映射数据,最后映射它某些DTO).完全重新映射到DTO是最大的efs利益之一的杀手;
     要么
   • 导致EF(和它的版本)和应用程序之间的强大凝聚力.这将是类似于2层应用程序与dal和演示文稿与bll或dal与bll和演示文稿.我想这不是最好的做法.除了映射之外,我们对之前的事情进行了相同的加载过程,因此再次提出了性能问题.我们可以尝试使用EF作为DAL而不需要任何抽象.但我们会以其他方式得到类似的问题.

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

3. 我们可以尝试仅使用EF + SP吗？我们再次提出以前的问题.如果不使用大部分功能,使用ef的原因是什么？

所以,EF是开始项目的好方法.当我们几乎没有屏幕和crud操作时,它非常方便.但接下来呢？

所有这些文字都只是未分类的想法.我知道纯粹的ado.net会带来另一种挑战.那么,您对此主题有何看法？

Answer 1

通过遵循命名约定,您会发现它被称为:ADO.NET实体框架,这意味着实体框架位于ADO.NET之上,因此它不能更快​​,它可以在相同的时间执行,但让我们来看看EF提供:

• 你不会再陷入编写查询的困境,而不知道你写的是否要编译.
• 它使您依赖C#或您喜欢的.NET语言来编写您希望直接从模型类中的目标用户接受的数据约束.

最后:EF和LINQ在以后维护您的应用程序方面给予了很大的帮助.

实体框架有三种不同的模型:模型优先,数据库优先和代码优先了解每个人.

- 重映射过程中杀死性能的要点正在进行中,因为在第一次运行时,EF将元数据加载到内存中,并且从edmx文件构建模型的内存表示时需要时间.