NHibernate在传统数据库上

如果你使用的是遗留数据库,你会发现ORM工具很难使用、配置、维护和优化。当我们使用NHibernate将我们的域模型映射到现有数据库时,我们遇到了许多问题。其中一些是:

1. Model对象很难映射到现有的表(我们有100多个表),NHibernate的一些要求非常突出,比如每个表都必须有一个ID字段才能映射到Domain对象。此外,映射多对多关系也很难掌握和使用。

2. 保持大容量 映射到所需的XML 遗留数据库成为全职 作为一名开发人员,这份工作相当不错 具有挑战性,特别是在一个团队中 10+开发人员。

3. 随着复杂性的增加,我们的查询性能下降,因为数据模型和对象模型并不总是与业务相匹配,需要不断调整。必须编写大量的数据聚合代码。例如,如果我们需要显示一个连接多个表的网格,我们过去必须加载多个域对象,将它们放在一起并显示在一个网格中。这段代码很难维护和调试。

4. 此外,有时我们不得不运行匿名查询,即我们只想从一些对象中获取一些属性,而不是整个对象。这真的很难编写、维护甚至实现,而且违背了ORM范式,但我们别无选择,只能这样做。

5. 我们遇到的另一个问题是,数据库不断变化,因为DBA会重构表,这总是会破坏我们的域对象。这是一次练习,目的是保持模型和表格的同步,并确保应用程序仍能正常工作。

长话短说。..我们了解到,如果有一种方法可以将业务所需的SQL直接映射到我们的UI模型或域对象,而不必担心配置,那将是一个更好的解决方案。

在经历了这段经历之后,我们开发了Orasis Mapping Studio。它是一个映射工具,专门用于处理遗留数据库和现有数据库。NET模型/域对象。它接受您的SQL查询,并允许您将其映射到现有的查询。NET对象,以图形方式显示Query和Object的元数据,并使用拖放在Object属性和Query列之间创建映射。该工具自动生成所有ADO。NET代码,您需要执行映射来读取对象。然后,您可以在DAL层中使用生成的代码,也可以使用生成的程序集来检索和持久化您的数据。

你可以在这里试试: Orasis Mapping Studio 。我们认为这是开发人员真正需要的工具,特别是用于处理遗留数据库以及性能是关键要求的情况。它是由开发人员为开发人员编写的,因此它处理了一些复杂的细节,如Obejct继承、嵌套对象、数据类型转换等。祝你好运

这将取决于你当前的数据库有多“NHibernate友好”。NHibernates喜欢单列主键(如果它们都命名为“id”就更好了)。据我所知,大多数ORM对存储过程不太友好。您是否考虑过如何定义传输对象以从数据库来回获取数据?

顺便说一句,没什么好羞愧的。ORM是一件好事,但你试图找到最佳方法是正确的。

我个人没有这样做,但您可以在映射文件中的命名查询中复制粘贴存储过程,并在以后逐一删除它们。

如果你对ORM没有任何经验,可能很难在大型遗留项目中开始学习它,因为你必须发现ORM的所有非标准功能,这些功能在绿地项目中不会使用,或者每年只使用一次。 NHibernate有很多支持遗留数据库的选项。

当你准备好跨越学习曲线,并有足够的勇气开始使用一项新技术时,你可以从NHibernate开始,但如果你想一步一步地学习新技术,我会等你开始一个新的绿地项目。

任何像样的ORM工具都应该支持逐步集成。这里的诀窍是在DAO级别(数据访问对象层)进行明确的分离。如果你可以通过一个定义良好的API来隐藏你的数据访问怪癖,那么你是否使用ORM就无关紧要了。

话虽如此,ORM引入的复杂性与表模型的复杂性直接相关。对于同一个表,你可以有许多不同的映射,只要确保你事先做了一些试验,以了解ORM解决方案的怪癖,比如有对象缓存、写后查询、代理访问等。 ORM解决方案的真正好处是使用对象而不是虚拟POJO类。这使得对业务进行更改比使用sproc或平面对象要容易得多。

顺便说一句,我参与了一个项目,我们将sproc中的整个应用程序迁移到了java。虽然我们没有使用sproc,但真正的痛苦是sproc架构没有很好地定义,许多sproc调用其他sproc使得一次迁移一些sproc变得非常困难。

NHibernate内部没有任何东西会限制你这样做。在某些时候,您可能希望将遗留代码转换为也使用NHibernate,因为在您能够导航所有对象之间的关系之前,您将无法看到ORM的全部好处。

最大的挑战可能是让你的遗留表结构适应NHibernate的每类单表方法。有办法解决这个问题,但这可能很棘手。不过,我认为这是值得的。

你提到过你正在远离当前的架构,但你是否需要坚持你的遗留数据库设计(例如,DBA严格负责设计和维护它),还是你当前的数据库设计也在重构(考虑使用O/R映射器)?

如果很难摆脱当前的传统设计,你可能会考虑研究其他类似的东西 iBATIS SqlMap-to-O/R使用普通的旧T-SQL查询将实体映射到遗留数据库,而不是使用不太灵活的Hibernate风格的XML/属性来映射数据。

根据您想如何处理设计,您可以使用 iBATIS SqlMap 通过使用您自己的摘要,可以透明地并排使用NHibernate DAO 工厂,或 iBATIS DataAccess API (它基本上做到了这一点,并且仍然与NHibernate兼容。)

我同意艾哈迈德的说法,我过去也遇到过类似的问题。我遇到的大部分麻烦不是来自技术本身,而是来自开发人员对它的采用,至少可以说,改用NHibernate意味着工作习惯的改变,这并不总是那么容易。

如果你是ORM的新手,最好用它开始一个全新的项目,而不是尝试转换一个遗留项目。

我建议将遗留项目转换为ORM,尝试使用LLBGen、.netTiers甚至Linq2SQL等生成工具。这样,你就可以在没有NHibernate可能强加的创伤性重写的情况下,对ORM感到更舒服。

为什么储存的procs“明显”不好?存储过程中的业务逻辑是否会造成痛苦?

微软似乎有许多可用的持久性技术(例如LINQ)。我不知道如何将它们与NHibernate进行比较,但除非你有真正好的对象可以映射,否则我不会推荐ORM。