Entity Framework VS pure Ado.Net
Entity Framework VS pure Ado.Net
EF是如此广泛使用的工具，但我不知道如何使用它。我在不同的项目中遇到了很多与EF相关的问题，采用了不同的方法。所以一些问题在我的脑海中聚集在一起。答案让我决定使用纯粹的ado.net和存储过程。
所以问题是：
1. 如何在多层应用程序中处理EF？
例如，我们有一些使用EF的数据访问层（DAL）。我看过很多文章和项目使用存储库、工作单元模式等作为EF的抽象。我认为这种方法会破坏增加开发速度的大部分好处，并导致以下几点：
- EF加载结果重新映射到某个DTO，会降低性能（首先进行某个查询以获取表数据，第二次循环是将结果映射到EF生成的某个复合类型，然后使用linq过滤映射的数据，最后将其映射到某个DTO）。重新映射到DTO正是EF最大的优势之一的杀手；
或者
- 会导致EF（及其版本）与应用程序之间存在很强的内聚性。这将是一种类似于两层应用程序的结构，其中包括数据访问层（DAL）和表示层或业务逻辑层（BLL）和表示层。我认为这不是最佳实践。与上述情况相同，加载过程也会导致性能问题上升。我们可以尝试将EF作为DAL使用，而不需要任何抽象层。但是我们会以其他方式遇到类似的问题。
2. 我应该在应用程序/线程/原子操作中使用一个context吗？使用每个应用程序/线程的方法可能会稍微提高性能并提供调用导航属性的可能性，但我们会遇到另一个问题-更新此context和在context中加载的数据的增长，我也对每个应用程序/线程使用一个dbcontext的并发性没有把握。使用每个操作一个context的方法将使我们将EF结果重新映射到我们的DTO。所以你可以看到我们又回到了第一题。
3. 我们可以尝试只使用EF +存储过程吗？同样，我们有了前面问题的困扰。如果大部分功能都不使用，那么使用EF的原因是什么呢？
所以，是的，EF是开始项目的好工具。当我们有一些屏幕和crud操作时，它非常方便。
但接下来呢？
这段文字只是一些杂乱的想法。我知道纯粹的ado.net会带来另一种挑战。
那么，你对这个话题有什么看法？