Fatal编程技术网
  • entity-framework/
  • Entity framework “拇指书写规则”；“查询”；使用ADO.NET实体框架

Entity framework “拇指书写规则”；“查询”；使用ADO.NET实体框架

entity-framework

Entity framework “拇指书写规则”；“查询”；使用ADO.NET实体框架,entity-framework,ado.net,Entity Framework,Ado.net,我目前正在开发一个中型web应用程序的原型，我认为也可以尝试使用实体框架。问题是，应用程序的主要部分不是数据层和逻辑，因此我没有太多时间使用实体框架。另一方面，数据库模式非常简单 我面临的一个问题是，我无法找到一种“编写查询”的一致方法。据我所知，这项工作有四个“接口”： LINQ到实体 使用LINQ扩展方法将LINQ转换为实体 实体SQL 查询生成器 好的，前两个基本上是相同的，但最好只使用一个来维护和保持一致性 我最困惑的是，它们似乎没有一个是完整的和最普遍的。我经常发现自己被逼得走投无

我目前正在开发一个中型web应用程序的原型，我认为也可以尝试使用实体框架。问题是，应用程序的主要部分不是数据层和逻辑，因此我没有太多时间使用实体框架。另一方面，数据库模式非常简单

我面临的一个问题是，我无法找到一种“编写查询”的一致方法。据我所知，这项工作有四个“接口”：

  • LINQ到实体
  • 使用LINQ扩展方法将LINQ转换为实体
  • 实体SQL
  • 查询生成器
好的，前两个基本上是相同的，但最好只使用一个来维护和保持一致性

我最困惑的是，它们似乎没有一个是完整的和最普遍的。我经常发现自己被逼得走投无路，并且使用了一些丑陋的组合。我的猜测是实体SQL是最通用的，但是使用字符串编写查询感觉像是后退了一步。我尝试类似实体框架的东西的主要原因是我喜欢编译时检查

其他一些随机想法/问题：

  • 我还经常使用ObjectQuery.Include（）方法，但它同样需要一个字符串。这是唯一的办法吗
  • 何时使用ObjectQuery.Execute（）（vs.ToList（））？它是否实际执行查询
  • 应该尽快执行查询（例如，使用ToList（）），还是我不介意让执行留给第一个遇到阻碍的枚举
  • ObjectQuery.Skip（）和ObjectQuery.Take（）是否仅作为扩展方法可用？有没有更好的方法进行分页？现在是2009年，几乎每个web应用程序都处理分页
总的来说，我理解在实现ORM时有很多困难，而且常常不得不妥协。另一方面，直接数据库访问（例如ADO.NET）简单明了，并且具有定义良好的接口（表格结果、数据读取器），因此所有代码——无论是谁编写的，何时编写的——都是一致的。我不想在编写数据库查询时面临太多的选择。这太单调了，不同的开发人员很可能会想出不同的方法

你的拇指规则是什么？

我尽可能多地使用LINQ来创建实体。我还尝试将lambda形式正式化，而不是扩展的SQL样式语法。我不得不承认，为了加快应用程序的编码，我在执行关系和降低效率方面遇到了问题（例如，主->子表可能需要手动加载），但总而言之，EF是一个好产品

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

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

a） 我创建了一个mediator对象，例如ClientSearchMediator，它“知道”如何按名称搜索客户机等。然后我可以通过SearchHandler.search（ISearchMediator[]mediators）调用（例如）来实现这一点。这可用于针对特定的数据结构，并使用LINQ to实体对结果进行相应排序

b） 对于更宽松的体验，可能是用户设计自己的查询（使用我们的应用程序提供的高级工具）的结果，eSQL是实现这一目的的理想选择。它可以保证注射安全。

我没有足够的知识来解决所有这些问题，但我至少要尝试一下

我不知道你为什么认为ADO.NET比实体框架更一致。使用ADO.NET有许多不同的方法，我肯定在单个代码库中看到了不一致性

Entity Framework目前是1.0版本，它存在许多1.0类型的问题（API不完整、不一致、缺少功能等）

关于包含，我想您指的是急切加载。很多人（微软以外的人）已经开发出了获取“类型安全”包含的解决方案（试着在谷歌上搜索：Entity Framework ObjectQueryExtension包含）。也就是说，Include更像是一个暗示。您不能强制立即加载，而且必须始终记住调用IsLoaded（）方法以查看您的请求是否得到满足。据我所知，“包含”的工作方式在Entity Framework的下一个版本（4.0-与VS2010一起发布）中根本没有改变

至于在构建Linq查询时执行Linq查询，而不是在最后一个可能的时刻执行Linq查询，这个决定是根据情况而定的。就我个人而言，除非有令人信服的理由不这样做，否则我可能会在大部分情况下一建成就执行它，但我可以看到其他人朝着相反的方向走

市场上有更成熟的ORM，实体框架不一定是您的最佳选择。在大多数情况下，您可以根据自己的意愿调整实体框架，但最终可能会推出自己的功能实现，这些功能是其他ORM现成的。

“使用LINQ扩展方法的LINQ到实体”：您是指LINQ到对象吗？因为LINQtoEntities也使用扩展方法……有趣的问题——我自己也遇到过类似的困惑，但这触及了问题的核心：应该如何使用LINQtoEntities？一致性很重要。@Yannick:我想这是因为有很多不同的方法来做同一件事。当然，
BLA.Select（x=>…myProjection…
与BLA-Select…myProjection…中x的
相同，但在代码中不一致地使用这两个选项会降低可读性