我是一名老派的数据库程序员。我一生都在通过 DAL 和存储过程使用数据库。现在我需要使用实体框架。
您能告诉我您的经验和架构最佳实践如何使用它吗？
据我所知，ORM 是为不懂 SQL 表达式的程序员设计的。这只是 ORM 的好处。我说的对吗？
我得到了架构文档，但我不清楚我应该用 ORM 做什么。我认为我的步骤应该是： 1) 创建完整的数据库 2）在模型中创建高级实体，例如“价格”，它实际上由几个数据库表组成 3) 在实体上映射数据库表。
【问题讨论】：
标签： entity-framework orm
ORM 不仅仅允许非 SQL 程序员与数据库对话！
ORM 无需处理大量手写 DAL 代码并获取数据的行/列表示，而是将表的每一行转换为强类型对象。
所以你最终得到例如Customer，您可以将其电话号码作为强类型属性访问：
string customerPhone = MyCustomer.PhoneNumber;
这比：
string customerPhone = MyCustomerTable.Rows[5].Column["PhoneNumber"].ToString();
在完成这项工作时，您不会从 IDE 获得任何支持 - 请注意列名输入错误！直到运行时你才会发现 - 要么你没有返回数据，要么你得到一个异常......不是很愉快。
首先，使用返回的 Customer 对象要容易得多，这些属性非常可用，是强类型的，并且可以在 Intellisense 中发现，等等。
因此，除了可能使您不必手工编写大量枯燥的 SQL 和 DAL 代码之外，ORM 还为使用数据库中的数据带来了很多好处——代码编辑器中的可发现性、类型安全等等。
我同意 - ORM 动态生成 SQL 语句并执行这些语句的想法可能很可怕。但至少在 Entity Framework v4 (.NET 4) 中，微软在优化所使用的 SQL 方面做得非常出色。在 100% 的情况下，它可能不是完美的，但在很大比例的情况下，它比任何非专业 SQL 程序员编写的任何 SQL 都要好得多......
另外：在 EF4 中，如果您真的想要并且看到需要，您可以随时定义和使用您自己的存储过程，用于在任何实体上进行 INSERT、UPDATE、DELETE。
【讨论】：
我可以理解您希望完全控制您的 SQL 的情绪。我自己一直在研究 ORM 的使用，虽然我不能像 marc_s 那样准确地陈述一个案例，但我想我可以补充几点。
我认为 ORM 的重点在于将重点从编写 SQL 和 DAL 代码转移到更多地关注业务逻辑。您可以使用 ORM 工具更加敏捷，因为您不必在每次更改对象模型时重构数据模型或存储过程。事实上，ORM 本质上为您提供了一个抽象层，因此您可以在不影响代码的情况下更改架构，反之亦然。 ORM 可能并不总是生成最有效的 SQL，但您可能会受益于更快的开发时间。然而，对于小型项目，ORM 的好处可能不值得花额外的时间配置 ORM。
我知道这并不能回答你的问题。
对于您的第二个问题，在我看来，S.O. 上有很多开发人员。这里对SQL非常熟练的人仍然提倡使用和自己使用的ORM工具，例如Hibernate、LINQ to SQL和Entity Framework。事实上，即使你使用 ORM，有时你仍然需要了解 SQL，而且通常是更复杂的查询，所以你关于 ORM 的理论主要是“给不懂 SQL 的程序员” 可能是错误的。此外，您还可以从 ORM 层获得缓存。
此外，Jeff Atwood 是 S.O. 的首席开发人员。 （这个网站在这里），声称他喜欢 SQL（我敢打赌他非常擅长它），并且他还努力避免在他的堆栈中添加额外的技术，但他选择使用 LINQ to SQL 来构建 S.O.多年前他已经声称，"Stored Procedures should be considered database assembly language: for use in only the most performance critical situations."
对于您的第一个问题，这是另一个article from Jeff Atwood's blog that talks about varies ways (including using ORM) to deal with the object-relational impedance mistmatch problem，它帮助我正确看待问题。这也很有趣，因为从那时起他对 ORM 的看法肯定发生了变化。在文章中他说你应该，“要么放弃关系数据库，要么放弃对象，” 以及，“我倾向于在数据库模型阵营的一方。”但正如我所说，一些要点帮助我正确看待事情。
【讨论】：