我目前正在研究中型Web应用程序的原型，我认为也可以尝试使用Entity Framework。问题是应用程序的主要部分不是数据层和逻辑，因此我没有太多时间来使用Entity Framework。另一方面，数据库模式非常简单。
我面临的一个问题是我找不到一种“编写查询”的一致方法。据我所知，这项工作有四个“接口”：
好的，前两个基本相同，但最好只使用一个来维护和保持一致。
我对这些事实感到困惑，因为它们似乎都不完整而且最普遍。我经常发现自己走投无路并且使用了一些丑陋的组合。我的猜测是实体SQL是最常用的，但使用字符串编写查询感觉就像退后一步。我正在尝试像Entity Framework这样的东西的主要原因是我喜欢编译时检查。
其他一些随机的想法/问题：
总的来说，我知道在实施ORM时存在许多困难，而且通常必须妥协。另一方面，直接数据库访问（例如ADO.NET）简单明了，并且具有良好定义的界面（表格结果，数据读取器），因此所有代码 - 无论是谁以及何时编写它 - 都是一致的。在编写数据库查询时，我不想面对太多选择。这太繁琐了，不同的开发人员可能会提出不同的方式。
你的拇指规则是什么？
答案 0 :(得分：2)
我尽可能使用LINQ-to-Entities。我也尝试将其形式化为lambda-form，而不是扩展的SQL风格语法。我必须承认在执行关系和妥协方面遇到问题只是为了加快我的应用程序编码（例如，Master-＆gt;子表可能需要手动加载）但总而言之，EF是一个很好的产品。
我确实使用EF的.Include（）方法进行延迟加载，正如你所说，它确实需要一个字符串输入。除了识别要使用的相对简单的字符串之外，我发现没有问题。我想如果你热衷于对这种关系进行编译时检查，那么类似于：Parent.GetChildren（）的模型可能更合适。
我的应用程序确实需要执行一些“动态”查询。我有两种方法可以满足这个要求：
a）我创建了一个中介对象，例如。 ClientSearchMediator，“知道”如何通过名称等搜索客户端。然后，我可以通过SearchHandler.Search（ISearchMediator [] mediators）调用（例如）。这可以用于定位特定的数据结构，并使用LINQ-to-Entities对结果进行排序。
b）对于更宽松的体验，可能是由于用户设计自己的查询（使用我们的应用程序提供的高级工具），eSQL非常适合此目的。它可以制成注射安全的。
答案 1 :(得分：1)
我没有足够的知识来解决所有这些问题，但我至少会采取一些措施。
我不知道你为什么认为ADO.NET比Entity Framework更加一致。有许多不同的方法可以使用ADO.NET，我肯定会在单个代码库中看到不一致。
实体框架目前是1.0版本，它存在许多1.0类型问题（不完整和不一致的API，缺少功能等）。
关于Include，我假设您指的是急切加载。多个人（在Microsoft之外）开发了用于获取“类型安全”的解决方案（尝试使用google搜索类似于：Entity Framework ObjectQueryExtension Include）。也就是说，Include更像是一种暗示。您无法强制执行加载，您必须始终记得调用IsLoaded（）方法以查看您的请求是否已满足。据我所知，“包含”的工作方式在下一版本的Entity Framework中没有任何变化（4.0 - 与VS 2010一起发布）。
就Linq查询的构建与最后可能的时刻一起执行时，该决定是情境性的。就个人而言，我可能会尽快执行它，除非有令人信服的理由不这样做，但我可以看到其他人走向相反的方向。
市场上有更成熟的ORM，实体框架不一定是您的最佳选择。在大多数情况下，您可以根据自己的意愿弯曲实体框架，但最终可能会推出自己的功能实现，这些功能与其他ORM一起开箱即用。