为什么 ORM 被认为是好的，而“select *”被认为是不好的？

ORM 通常不涉及执行诸如 select * 之类的操作吗？

如果我有一个表 MyThing，其中包含 A、B、C、D 等列，那么通常会有一个对象 MyThing，其属性为 A、B、C、D。

如果该对象没有被如下所示的 select 语句完全实例化，只获取 A、B，而不获取 C、D，那将是邪恶的：

select A, B from MyThing /* 不要获取 C 和 D，因为我们不需要它们 */

但总是这样做也是邪恶的：

select A, B, C, D /* 获取所有列，以便我们可以完整实例化 MyThing 对象 */

ORM 是否假设数据库访问速度如此之快，您现在不必担心它，因此您始终可以获取所有列？

或者，您是否有不同的 MyThing 对象，一个对应于 select 语句中可能出现的每一列组合？

编辑：在回答问题之前，请阅读 Nicholas Piasecki 和 Bill Karwin 的答案。我想我的问题问得不好，因为很多人都误解了，但尼古拉斯百分百理解。和他一样，我对其他答案感兴趣。

编辑#2：与此问题相关的链接：

为什么我们需要实体对象？ https://stackoverflow.com/questions/18655/why-do-we-need-entity-objects

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx，尤其是“部分对象问题和加载时间悖论”部分

http://groups.google.com/group/comp.object/browse_thread/thread/853fca22ded31c00/99f41d57f195f48b http://groups.google.com/group/comp.object/browse_thread/thread/853fca22ded31c00/99f41d57f195f48b?

http://www.martinfowler.com/bliki/AnemicDomainModel.html http://www.martinfowler.com/bliki/AnemicDomainModel.html

http://database-programmer.blogspot.com/2008/06/why-i-do-not-use-orm.html http://database-programmer.blogspot.com/2008/06/why-i-do-not-use-orm.html

根据我有限的经验，事情正如你所描述的那样——这是一个混乱的情况，通常的逃避“这取决于”的答案适用。

我工作的在线商店就是一个很好的例子。它有一个Brand对象，在网站的主页上，商店销售的所有品牌都列在左侧。要显示此品牌菜单，站点需要的只是整数BrandId和字符串BrandName。但是Brand对象包含一整套其他属性，最值得注意的是Description可以包含大量有关该属性的文本的属性Brand。没有两种方法可以解决这个问题，加载有关该品牌的所有额外信息只是为了在无序列表中吐出其名称，这是（1）明显且明显缓慢的，通常是因为文本字段很大，并且（2）当它出现时效率非常低内存使用情况，构建大字符串，甚至在扔掉它们之前都不看它们。

许多 ORM 提供的一种选项是延迟加载属性。所以我们可以有一个Brand对象返回给我们，但是那个耗时又浪费内存Description直到我们尝试调用它的字段get访问器。此时，代理对象将拦截我们的调用并及时从数据库中获取描述。有时这已经足够好了，但已经让我很恼火了，我个人不推荐它：

• 人们很容易忘记该属性是延迟加载的，仅通过编写 foreach 循环就会引入 SELECT N+1 问题。谁知道当 LINQ 介入时会发生什么。
• 如果即时数据库调用因传输混乱或网络故障而失败怎么办？我几乎可以保证任何代码都会做一些无害的事情string desc = brand.Description没想到这么简单的调用就扔了一个DataAccessException。现在你刚刚以一种令人讨厌且意想不到的方式崩溃了。 （是的，我已经看到我的应用程序因此而严重下降。经历了惨痛的教训！）

因此，我最终所做的是，在需要性能或容易出现数据库死锁的情况下，我创建一个单独的接口，网站或任何其他程序可以调用该接口来访问已进行查询的特定数据块计划经过仔细审查。该架构最终看起来有点像这样（原谅 ASCII 艺术）：

Web Site:         Controller Classes
                     |
                     |---------------------------------+
                     |                                 |
App Server:       IDocumentService               IOrderService, IInventoryService, etc
                  (Arrays, DataSets)             (Regular OO objects, like Brand)
                     |                                 |
                     |                                 |
                     |                                 |
Data Layer:       (Raw ADO.NET returning arrays, ("Full cream" ORM like NHibernate)
                   DataSets, simple classes)
  

我曾经认为这是作弊，颠覆了OO对象模型。但从实际意义上来说，只要你做到这个显示数据的快捷方式，我觉得就可以了。更新/插入以及您仍然需要经历完全水合、ORM 填充的域模型，而这种情况发生的频率远低于显示特定数据子集（在我的大多数情况下）。像 NHibernate 这样的 ORM 可以让你进行投影，但到那时我还没有看到 ORM 的意义。无论如何，这可能是一个存储过程，编写 ADO.NET 需要两秒钟。

这只是我的两分钱。我期待着阅读其他一些回复。