Fatal编程技术网
  • sql/
  • Sql ORM有什么了不起的地方？

Sql ORM有什么了不起的地方？

sql performance nhibernate orm subsonic

Sql ORM有什么了不起的地方？,sql,performance,nhibernate,orm,subsonic,Sql,Performance,Nhibernate,Orm,Subsonic,所以我有一个头靠着墙的时刻，希望有人能来帮忙，要么拆墙，要么阻止我的头移动 在过去的3/4周里，我一直在为一个新项目调查ORM的准备情况。ORM必须映射到现有的大型老化SQL数据库 所以我尝试了亚音速。我真的很喜欢v2和v3，在修改后可以很好地与VB配合使用，并且SQL中的命名模式运行正常。然而，它缺乏将实体属性名与列名分开的灵活性，这让我非常恼火（抱歉，Rob） 我尝试了实体框架，但我发现和其他人一样，它在某些方面有所欠缺 所以我咬紧牙关，尝试了nHibernate，但在一周左右的时间里，它以

所以我有一个头靠着墙的时刻，希望有人能来帮忙，要么拆墙，要么阻止我的头移动

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

所以我尝试了亚音速。我真的很喜欢v2和v3，在修改后可以很好地与VB配合使用，并且SQL中的命名模式运行正常。然而，它缺乏将实体属性名与列名分开的灵活性，这让我非常恼火（抱歉，Rob）

我尝试了实体框架，但我发现和其他人一样，它在某些方面有所欠缺

所以我咬紧牙关，尝试了nHibernate，但在一周左右的时间里，它以我喜欢的方式工作（在Codesmith的帮助下为我生成类/HBM），我对启动（构建配置对象）所需的时间感到沮丧，尽管我尝试了一些技巧来减少这段时间

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

对不起，我问的问题太过分了。我的头发不多了，我想保留我的头发

提前谢谢你，埃德

另外，我应该补充一点，我对SQL非常了解，也不怕脏手去写快速查询。根据我的经验，如果我不需要对SQL隐藏任何东西，那么大多数ORM最终都比SQL复杂得多。这违背了使用它们的全部目的

我热衷的一个解决方案是LINQ2SQL。它作为一个关于存储过程或视图的薄层表现得非常出色。它非常易于使用，而且不会试图隐藏SQL。

ORM让我们为您：

  • 将表行映射到对象，这是面向对象编程的可行部分
  • 自动浏览对象关系的步骤
  • 轻松添加、编辑和删除表行的步骤
  • 以更直观的方式查询数据库，因为您不必考虑连接（这取决于ORM和查询方法）
  • 以透明方式处理一级缓存和二级缓存
    • 如果不使用ORM，以上所有操作都必须手动完成

    PS：我同意Dmitry关于NHibernate的启动时间（见问题注释）。另外，你试过了吗？流利的NHibernate令人印象深刻地简单。当我第一次映射数据库时，我简直不敢相信自己的眼睛。它甚至比专有的ORMs（如DevExpress XPO）更容易。

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

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

    我认为对于新项目来说，ORM工具是必要的。对于遗留项目来说，这没有多大好处，除非你有时间/金钱从头开始。

    这里基本上有两个问题：

    ORMs有什么好处？关于Stackoverflow也有类似的问题。见：

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

    您有什么样的应用程序使得nhibernate的启动时间成为一个问题？在我看来，只有当你直接从桌面访问DB时，这才应该困扰你，而不是在中间层服务的情况下。你可以通过简单地问“我如何加快NHibernate应用程序的启动时间？”来简化这个问题。Andre-我希望从桌面使用NHibernate！作为类库的一部分，将由许多帮助程序应用程序引用。其中一些小应用程序需要几秒钟才能运行，使用传统ado.net方法没有问题，但使用NHibernateMichael很痛苦——我尝试了这两种建议——将所有映射放在一个hbm文件中，并对hbm进行二进制序列化。两者都有所改进，但仍有明显的滞后。推荐FluentNHibernate时+1。目前在一个项目中使用它，它真的是“令人印象深刻的简单”。+1强调解耦。这就是我大力提倡使用ORM工具和存储库模式的原因。ORM工具无助于解耦。表示逻辑仍然可以通过ORM机制使用ADO.NET或SQL与数据库对话。LinqToSql希望成为您的业务层，实际上使业务逻辑和数据逻辑分离变得很棘手。在大多数情况下，除了非常基本的CRUD和按名称/id类型的查询外，ORMs无法对您隐藏任何SQL。ORM对遗留项目很有用，但对新项目并不总是有意义。ORM工具确实有助于解耦。正如我所写的，这不是您需要做的唯一事情，因为您仍然需要定义接口方法，这将隐藏对ORM库的依赖关系。然而，这些方法可以使用ORM工具创建的“Customer”或“Order”类，并映射到数据库；大多数ORM工具的配置极其复杂。我认为它们确实解决了一系列非常复杂的问题来证明它们的复杂性，而且使用它们所获得的价值超过了学习如何使用它们的代价。Andromar:ORM通常是公开对象，而不是SQL。这就是重点。如果不映射关系，为什么要使用ORM