entity-framework - 使用 ADO.NET Entity Framework 编写 "queries"的经验法则

Question

我目前正在开发一个中型 Web 应用程序的原型(prototype)，我认为也可以尝试使用 Entity Framework。问题是应用程序的主要部分不是数据层和逻辑，所以我没有太多时间玩 Entity Framework 。另一方面，数据库模式非常简单。

我面临的一个问题是我找不到一致的方式来“编写查询”。据我所知，这项工作有四个“界面”:

LINQ 到实体

使用 LINQ 扩展方法的 LINQ to Entities

实体 SQL

查询生成器

好的，前两个基本相同，但最好只使用一个来维护和保持一致性。

我最困惑的是，它们似乎都不完整且最笼统。我经常发现自己走投无路，并使用其中几个看起来难看的组合。我的猜测是 Entity SQL 是最通用的，但使用字符串编写查询感觉像是退后一步。我尝试使用 Entity Framework 之类的东西的主要原因是我喜欢编译时检查。

其他一些随机的想法/问题:

我也经常使用 ObjectQuery.Include() 方法，但它同样需要一个字符串。这是唯一的方法吗？

何时使用 ObjectQuery.Execute()(相对于 ToList())？它真的执行查询吗？

应该尽快执行查询(例如使用 ToList())，还是我应该不在乎让第一个妨碍的枚举执行？

ObjectQuery.Skip() 和 ObjectQuery.Take() 是否只能作为扩展方法使用？有没有更好的方法来进行分页？现在是 2009 年，几乎每个 Web 应用程序都在处理分页。

总的来说，我理解在实现 ORM 时会遇到很多困难，而且常常不得不妥协。另一方面，直接数据库访问(例如 ADO.NET)简单明了，并且具有定义明确的接口(interface)(表格结果、数据读取器)，因此所有代码——无论是谁、何时编写——都是一致的。我不想在编写数据库查询时面临太多选择。这太乏味了，而且很可能不同的开发人员会想出不同的方法。

你的经验法则是什么？

Answer 1

我尽可能多地使用 LINQ-to-Entities。我还尝试将其形式化为 lambda 形式，而不是扩展的 SQL 样式语法。我不得不承认，为了加快我对应用程序的编码(例如，可能需要手动加载主 -> 子表)，在执行关系和效率上做出妥协时遇到了问题，但总而言之，EF 是一个很好的产品。

我确实使用 EF 的 .Include() 方法进行延迟加载，正如您所说，它确实需要字符串输入。我发现这没有问题，除了识别要使用的字符串相对简单。我想如果您热衷于对此类关系进行编译时检查，则类似于: Parent.GetChildren() 的模型可能更合适。

不过，我的应用程序确实需要执行一些“动态”查询。我有两种方法可以解决这个问题:

a)我创建了一个中介对象，例如。 ClientSearchMediator，它“知道”如何按名称搜索客户等。然后我可以通过 SearchHandler.Search(ISearchMediator[] mediators) 调用(例如)。这可用于针对特定的数据结构并使用 LINQ-to-Entities 对结果进行相应的排序。

b) 对于更宽松的体验，可能是由于用户设计了自己的查询(使用我们的应用程序提供的高级工具)，eSQL 非常适合此目的。它可以制成注入(inject)安全的。