从SQL到EF6我应该从哪个加载方法开始？延迟加载，显式加载，急切加载

Question

第一个问题和通用但我没有找到任何帮助。

我首先使用EF6代码构建一个新项目。我理解Lazy，Eager和Explicit加载之间的区别。我不确定的是我应该从哪开始。即我正在利用EF＆amp; Linq但后来花了多少钱。

以前我会写一个特定的SQL查询来获取一组特定的数据。使用EF我有很大的灵活性，我担心我可以冒险进行加载路线，但是当我开始处理性能和优化时，我可能会受到限制和/或切换加载方法可能会很耗时。

问题是，如果我从延迟加载和虚拟属性开始，之后管理性能并切换到更具体的加载是否容易，或者在开始项目之前是否应该全部设计？或者从显式加载开始，关闭延迟加载？

此致

Answer 1

如果不了解您正在尝试构建的系统，我将从延迟加载开始。您应该注意的主要性能问题是N + 1 problem。

如果您发现自己需要经常迭代依赖对象，请考虑另一种解决方案，例如使用Include，或使用单独的查询在单个语句中检索所有依赖对象，然后根据需要在代码中连接这两个集合。

如果您的系统专注于报告，那么EF可能不是最佳选择。通常，报告需要连接许多依赖对象才能生成正确的输出。请记住，EF是一个ENTITY框架，实体的属性与CRUD操作有关，而不是报告。

Answer 2

更重要的考虑因素是：如何管理上下文实例的生命周期？

通常的做法是拥有短暂的背景。这意味着：获取数据，处理上下文并继续前进。反过来，这通常意味着您希望在上下文的生命周期内加载特定用例所需的数据。反过来，那意味着你通常会使用预先加载，并且还会做一切事情以防止在处理上下文后触发延迟加载（因为这会引发异常）。

Answer 3

我的经验：我作为初学者开始使用延迟加载，然后当perf变得不可接受时开始使用Include。现在我几乎总是手动编写查询，因为我也超过了Include。性能越重要，您就越不方便。代码库越复杂，要求越高，你被迫控制的越多。

通常情况下，延迟加载只需要一段时间，下一刻你需要进行手动查询并删除所有延迟加载的东西。过渡往往是突然而激进的。示例：您在页面上呈现问题列表。现在，您还要为每个问题显示question.Answers.Count（）。延迟加载不能这样做。现在，您需要引入自定义视图模型和自定义查询（questions.Select(q => new { q.ID, q.Title, AnswerCount = q.Answers.Count() })）。这种情况迟早会在业务需求增加的情况下发生。我通常直接使用手动查询。

为了澄清，除了使用自定义查询之外，没有很好的方法来解决我刚给出的示例。如果你在开发项目的第一个版本时没有查询，你可能必须告诉客户这个小小的改变（只是增加的答案数）将花费很多钱，因为你现在必须重写页面的某些部分。以后，缺乏灵活性往往会很昂贵。

另外，请参阅问题下的评论以获取更多背景信息。