有些团队会弃用对象关系映射框架（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在运行以及它的性能如何是很重要的。

ORM不好用，也许是因为你在以错误的方式在使用