ORM 有什么了不起的？答案

【问题标题】：What is so great about ORM?ORM 有什么了不起的？
【发布时间】：2010-02-09 10:51:40
【问题描述】：

所以我现在正头撞墙，希望有人能来帮助拆除墙壁或阻止我的头移动！！

在过去的 3/4 周里，我一直在调查 ORM 是否为新项目做好准备。 ORM 必须映射到现有的、大型且老化的 SQL 数据库。

所以我尝试了 Subsonic。我真的很喜欢 v2 和 v3 修改后可以很好地与 VB 一起工作，并且 SQL 中的命名模式运行正常。但是，它缺乏将实体属性名称与列名称分开的灵活性，这让我大吃一惊（抱歉 Rob）。

我尝试了 Entity Framework，但我发现它和其他人一样在某些领域缺乏。

所以我硬着头皮尝试了 nHibernate，但大约一周后让它按我喜欢的方式工作（在 Codesmith 的帮助下为我生成类/hbms）我对启动所需的时间感到沮丧（构建一个config 对象），尽管尝试了一些技巧来减少这个时间。

我基本上是在构建一个可以在应用程序和网站之间共享的 DAL 类。我在吠叫错误的树吗？对于具有 100 多个表的遗留项目，我应该返回 ado.net 并使用 DTO 吗？啊！

很抱歉问题的粗鲁风格。我的头发不多了，我想保留我的头发！！

提前致谢，埃德

PS。我应该补充一点，我非常了解 SQL，并且不怕弄脏我的手来编写快速查询。如果有什么我不需要对 SQL 隐藏

【问题讨论】：

你有什么样的应用程序，所以 nhibernate 启动时间是一个问题？ IMO，如果您直接从桌面访问数据库，它只会打扰您，而不是在中间层服务的情况下。
您可以通过简单地询问“如何加快 NHibernate 应用程序的启动时间？”来简化这个咆哮。
Andre - 我希望从桌面使用 NHibernate！作为类库的一部分，将被许多帮助应用程序引用。其中一些小应用程序需要几秒钟才能运行，使用传统的 ado.net 方法没有问题，但使用 NHibernate 会很痛苦
Michael - 我已经尝试了这两个建议 - 将所有映射放在一个 hbm 文件和 hbm 的二进制序列化。两者都有改进，但仍然存在明显的滞后。

标签： sql performance nhibernate orm subsonic

【解决方案1】：

ORM 让你：

将表行映射到对象，这是面向对象编程的可行部分。
自动浏览对象关系
轻松添加、编辑和删除表格行
以更直观的方式查询数据库，因为您不必考虑连接（这取决于 ORM 和查询方法）
透明地处理 L1 和 L2 缓存。

如果您不使用 ORM，以上所有内容都必须手动处理。

PS：我同意 Dmitry 关于 NHibernate 的启动时间（参见问题 cmets）。另外，你试过Fluent NHibernate吗？ Fluent NHibernate 非常简单。当我第一次映射数据库时，我简直不敢相信自己的眼睛。它甚至比 DevExpress XPO 等专有 ORM 更容易。

【讨论】：

+1 推荐 FluentNHibernate。目前在一个项目中使用它，它确实“非常简单”。

【解决方案2】：

ORM 工具的最大好处是它可以帮助您正确地分层应用程序。现在大多数项目都使用数据层连接到数据库。您从 ORM 工具开始生成与您的数据库对象相对应的类。然后使用这些方法定义一个接口。所有的持久化代码都使用这个接口的方法。这样业务逻辑层只耦合到这个更高层的接口，对数据库一无所知。实际上不应该依赖 ADO.NET 甚至 NHibernate。

ORM 工具的另一个优点是您可以将应用程序与数据库服务器分离。您可以更改数据库引擎并仍然使用相同的代码。此外，ORM 对您隐藏的不仅仅是 SQL 的复杂性。它还可以帮助您处理事务逻辑和连接池。

我想说，对于新项目，ORM 工具是必不可少的。对于遗留项目，它并没有太大的好处，除非你当然有时间/金钱从头开始。

【讨论】：

+1 强调解耦。这就是我强烈提倡 ORM 工具和利用存储库模式的原因。
ORM 工具无助于解耦。表示逻辑仍然可以使用 ADO.NET 或 SQL 通过 ORM 机制与数据库对话。 LinqToSql 想成为您的业务层，实际上使分离业务和数据逻辑变得很棘手。在大多数情况下，除了非常基本的 CRUD 和按名称/id 类型的查询查找之外，ORM 无法向您隐藏任何 SQL。 ORM 对遗留项目很有用，但对新项目并不总是有意义。
ORM 工具 do 有助于解耦。正如我所写的，这不是您唯一需要做的事情，因为您仍然需要定义接口方法，这将隐藏对 ORM 库的依赖关系。然而，这些方法可以使用使用 ORM 工具创建并映射到数据库的类，如“客户”或“订单”。

【解决方案3】：

根据我的经验，大多数 ORM 最终都比 SQL 复杂得多。这违背了使用它们的全部目的。

我热衷的一个解决方案是 LINQ2SQL。它擅长作为存储过程或视图的薄层。它真的很容易使用，并且不会试图隐藏 SQL。

【讨论】：

我可以同情复杂性的问题；大多数 ORM 工具的配置都极其复杂。我认为它们确实解决了一系列非常复杂的问题以证明它们的复杂性，并且使用它们所获得的价值超过了学习如何使用它们的代价。
Andomar：一般来说，ORM 是公开对象，而不是 SQL。这就是重点。如果不将关系表映射到对象上，为什么还要使用 ORM？也许 ADO.NET 更适合您的需求。
Andomar：你看过@PLINQO 吗？我用它和 Codesmith 映射了同一个数据库，最终得到了更少的错误和更快的执行时间——没有开箱即用的启动延迟。

【解决方案4】：

这里基本上有两个问题：

ORM 有什么好处？ Stackoverflow 上有类似的问题。见：

如何提高 NHibernate 的启动时间？见：

【讨论】：