我昨晚读了this post，我注意到它是从 2006 年开始的。我可以在 ORM、数据库方面采取任何一种方式，但我只是想知道 Jeff 所说的关于 ORM 的所有坏话是否仍然适用，即使现在考虑到这篇文章是从 2006 年开始的。
【问题讨论】：
标签： database language-agnostic orm
披露：我是RDO.Net的作者。
是的。我相信现有的 ORM 正朝着错误的方向发展——他们试图将关系数据映射到任意对象中，恕我直言，这是不可能的。在 OO 世界中，任意对象不是序列化/反序列化友好的，因为每个对象都有一个当前进程本地的对象引用（地址）。处理单个对象没问题，遇到复杂对象图就麻烦了。
希望这个问题可以使用不同的方法来解决，如RDO.Net：我们不是将关系数据映射到任意对象，而是将数据的模式映射为丰富的元数据（Model 包含列，主要/外部密钥、验证等），并公开具体的Db、DbTable、DbQuery 和DataSet 以进行数据访问。执行数据库 CRUD 操作时，您可以使用强类型 OO 语言显式构建 SQL 抽象语法树 (AST)，如以下示例 C# 代码所示，该代码创建查询并返回分层数据的 DataSet：
public async Task<DataSet<SalesOrderInfo>> GetSalesOrderInfoAsync(_Int32 salesOrderID, CancellationToken ct = default(CancellationToken))
{
var result = CreateQuery((DbQueryBuilder builder, SalesOrderInfo _) =>
{
builder.From(SalesOrderHeader, out var o)
.LeftJoin(Customer, o.FK_Customer, out var c)
.LeftJoin(Address, o.FK_ShipToAddress, out var shipTo)
.LeftJoin(Address, o.FK_BillToAddress, out var billTo)
.AutoSelect()
.AutoSelect(c, _.Customer)
.AutoSelect(shipTo, _.ShipToAddress)
.AutoSelect(billTo, _.BillToAddress)
.Where(o.SalesOrderID == salesOrderID);
});
await result.CreateChildAsync(_ => _.SalesOrderDetails, (DbQueryBuilder builder, SalesOrderInfoDetail _) =>
{
builder.From(SalesOrderDetail, out var d)
.LeftJoin(Product, d.FK_Product, out var p)
.AutoSelect()
.AutoSelect(p, _.Product)
.OrderBy(d.SalesOrderDetailID);
}, ct);
return await result.ToDataSetAsync(ct);
}
【讨论】：
恕我直言，像 Scala 的 Slick 和 Quill 这样的 Monadic 方法在很大程度上绕过了上述泥潭，为 Ted 的许多问题提供了更强大的解决方案（JOOQ 也值得一提）。虽然它们并不完美，但它们肯定会解决 N+1 和 Partial Object 问题，主要解决 Identity 问题，部分解决 Dual Schema 问题。忘掉笨拙和冗长的 CriteriaBuilder 查询（任何人都读过“名词王国中的执行？？？”），Scala 的一元 for-comprehensions 为您提供了一个简单的 DSL 来编写标准查询：
case class Person(id: Int, name: String, age: Int)
case class Contact(personId: Int, phone: String)
val query = for {
p <- query[Person] if(p.id == 999)
c <- query[Contact] if(c.personId == p.id)
} yield {
(p.name, c.phone)
}
这种语法保持理智，即使对于更复杂的查询，例如Ted 的是否可接受配偶查询：
case class Person(name:String, spouse:Option[PersonId]) {
isThisAnAccpetableSpouse(person:Person) {...}
}
val query = for {
p1 <- people
p2 <- people if (
p1.spouse.isEmpty && p2.spouse.isEmpty
&& p1.isThisAnAccpetableSpouse(p2)
&& p1.isThisAnAccpetableSpouse(p1))
} yield (p1, p2)
所有这些都被编译成一个 SELECT 查询并针对数据库运行。插入、更新和删除是类似的。
【讨论】：
Jeffs 文章链接到 Ted Newards 文章。如果您了解细节，那么您需要查看那里：
原创 - http://blogs.tedneward.com/post/the-vietnam-of-computer-science/
跟进 - http://blogs.tedneward.com/post/thoughts-on-vietnam-commentary/
Ted 的原点我有：
免责声明：我是 Ebean ORM 的作者，因此我将参考它来解决所提出问题的各种“解决方案”。
Ted 的原点（因为实在是罗嗦所以提炼出来）：
1.部分对象问题。
总是可以解决的。 Ebean ORM 使部分对象成为其查询语言和所有内部结构的基础。不幸的是，JPQL 并没有将此作为优先事项。
2。 N + 1（Ted 的加载时间悖论）
总是可以解决的。应该写成1 + N / batchSize，但它比这更有趣（每个路径，需要考虑SQL分页，避免sql笛卡尔积）。不幸的是，一些 ORM 把这件事弄得一团糟，这使 ORM 总体上声名狼藉。一些 ORM 是可以的，直到您达到一定程度的复杂性（例如 OneToMany 中的 OneToMany 中的 OneToMany）。
为了提高赌注，ORM 可以分析对象图的使用并自动优化查询（只获取需要的内容，定义获取路径以优化 N + 1 等）。
这种自动 ORM 查询优化的想法来自德克萨斯大学（使用 Hibernate）。它在 2008 年作为 Ebean ORM 的一部分包含在内，所以它已经存在了一段时间。
3.身份
Ted 破解了身份和并发性不匹配的问题。这一点是错误的，因为 ORM（好吧，我所知道的所有）在这方面完全与以前的客户端/服务器工具相同，特别是 ORM 提供 SNAPSHOT strong> 向应用程序查看部分数据库。这里从来没有问题，但 ORM 实现可能会因过度依赖 hashCode()/equals() 而陷入冲突。
4.双模式问题
这是有争议的。如果组织允许，那么 ORM 可以向架构提供 DIFF/SQL 脚本，该脚本由 FlywayDB/Liquibase 等运行。如果组织不允许，这在某种程度上可能仍然是一个问题。
5.数据库重构/共享架构
这是有争议的。 DB 设计/规范化人员会争辩说，DB 设计应该达到 4NF，这意味着任何重构都应该只是附加的（非规范化、添加列/表）而不是破坏性更改。不相信规范化的人会因为担心共享模式而发疯。
【讨论】：
许多 web 2.0 公司都在致力于键值存储。而且所有这些公司都必须经历同样痛苦的过程才能使其运作。
如果 ORM 是“计算机科学的越南”，那么构建自己的键值存储可能就是“计算机科学的伊拉克”:-)
【讨论】：
我认为从 Jeff 的结论正确的假设出发并不一定是好的；在维护了存储过程代码以及基于 JDBC 的数据层之后，我可以说这些都会导致大量的维护问题，主要与无法理解更高级别发生的事情有关。
数据库必然是低级的；它本质上存储数字和字符串。业务逻辑是高级别的。这就是我们有抽象的原因。
就我个人而言，我认为 Rails/ActiveRecord 方式是拥有对象/域模型但也能够利用关系数据库的最佳解决方案。
所以：不要丢弃 ORM，但也不要默认使用它。它是解决某些问题的工具。忽视它是无知的，总是使用它是傲慢的。
【讨论】：
是的。
面向对象仍然是面向对象，而关系仍然是面向集合。在过去的两年中，这两种范式没有发生任何变化，以使它们更好地协同工作。
在许多人眼中，SQL 丑陋、复杂且令人困惑。但是试图创建一个面向对象的接口来执行相同的功能总是更丑陋、更复杂，并且学习曲线更陡峭。
在所有编程中，灵活性和假设之间都有一个折衷。框架（例如 Rails）试图通过“固执己见”来解决问题。也就是说，它们限制了问题的关系或面向对象方面的灵活性，对数据的结构方式以及您可以对其进行哪些操作进行假设。当然，简化问题空间也会使解决方案更简单。
此外，发现一个ORM框架是不完整的，令人沮丧，因此SQL中的一些普通操作在给定的ORM中没有解决方案。这也是“固执”框架的结果。
【讨论】：
我只能代表我的经验。我使用 DAL 和 DTO，我仍然能够执行非常复杂的查询（连接和所有），并且我可以在需要时使用 SP 或自定义 SQL。它让我的生活更轻松，我的代码更一致，我的最后期限更容易实现。
【讨论】：
这仍然是真的。
与 OO 软件相比，如果没有按照预期的方式精确处理数据库，数据库也会受到影响。并且不打算在它前面插入一些抽象层。
我认为不透水的抽象层就像试图建造一座乐高城堡，所有的零件都封闭在一个枕套中。 SQL 很难正确执行。它与过程式编程没有很多相同的模式，一个最佳实践可能与另一个相反。您需要能够理解 SQL 语句中的每一个项目，并且非常清楚它的意图是什么，以及它实际上做了什么。
很多人似乎认为，就像马蹄铁一样，接近就足够了 - 如果弹出正确的答案，那就意味着你快到了。在 SQL 中，这根本不是真的。
出于这个原因，RoR 和 ActiveRecord 模式当之无愧地赢得了 dbms 资源消耗者的美誉。优化的 ActiveRecord 设计往往不是次优的 SQL 设计，因为它鼓励 SQL 语句分解。
【讨论】：
这不是我的专业领域，但我在 Rails 工作了大约一年，我认为 ActiveRecord 解决了大部分数据库映射问题。我意识到它存在一些问题，但我认为它做得非常好。
我认为他的帖子没有考虑到框架本身（在本例中为 AcitveRecord/Rails）定义数据库和对象模型的可能性，据我所知，这使问题解决了离开。
由于这与前两个回复相反（基本上是帖子已过时），我觉得我可能不理解某些东西；如果是这种情况，请纠正我，而不是仅仅投反对票，因为我认为我遗漏了重要的一点。
【讨论】：
我认为是的。
我认为最后一句话是最有趣的：“我倾向于选择数据库模型阵营，因为我认为对象被高估了。” Java、C++ 和 C# 无疑是主要语言，但函数式编程正在与 F#、Scala 等一起卷土重来。
【讨论】：