团队弃用一种对象关系映射框架（ORM），因为他们认为它性能不够好或者增加了太多不可知的因素，但那通常是由于用法不对。在最近的一次演讲中， Jimmy Bogard 着重强调了在使用 ORM 时他认为正确和错误的方式，其中包括映射和查询问题。
Jimmy 是 AutoMapper 的创建者，同时也是一位微软最有价值专家。他将ORM 描述成一种从数据库获取数据并传递给应用程序以及将数据传回数据库的工具。这可能看上去是个简单的问题，但实际上却相当复杂。
Jimmy 描述的一个映射问题是数据库生成的映射代码，即由工具从现有的数据库创建代码。这看上去可能很有吸引力，但他通常会发现，其中有太多的关系和不必要的导航，这会产生性能问题。相反，Jimmy 使用代码优先的方式，添加他们需要的映射和关系，即使对于已经存在的数据库，也是如此。
以 Jimmy 的经验来看，在使用 ORM 时，开发人员抱怨的第一件事往往是过度延迟加载和 Select N+1 加载，这些特性会使 ORM 延迟加载一个复杂模型中的所有数据，而不是按需读取数据。问题在于，那可能会导致许多数据库调用，例如，一次读取一个属性或者在集合上循环时。相反，Jimmy 更倾向于尽可能多地使用“预先抓取（eager fetch）”，在一次请求中读取所有需要的数据。
Jimmy 认为， Repository 模式并不是一个好主意。在《领域驱动设计》原书中，Repository 原本是一个接口，看上去像数据存储上的一个集合，但Jimmy 认为，这种模式已经演变成ORM 之上的外观模式，隐藏了许多ORM 特有的特性。在这种模式下，Repository 只是一个愚蠢的接口，有一个仅仅作为实际ORM 代理的实现。要有效地使用ORM，就要使用这些隐藏的特性。这会使ORM 的实现细节暴露给应用，使Repository 成为ORM 上一个中看不中用的包装器。
作为Repository 的替代方案，Jimmer 更倾向于将处理特定请求的所有代码放入一个类中，从而将每个数据请求建模成一个命令或者一个查询。这样，变化，比如一种新的数据访问策略，就封装到一个特定的类中。
Jimmy 提到的最后一个糟糕的观念是忽略 SQL。ORM 不是一种避免了解 SQL 的方法，对于运行在 ORM 上的关键业务系统，知道什么 SQL 在运行以及它的性能如何是很重要的。
查看英文原文：**** You Are Using the ORM the Wrong Way
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论 1 条评论