2

不久前，我们开始开发一个新项目，该项目内部有大约 25-30 个不同的类/类型/模型，它们通过 1:n、n:m 或 n:1 关系彼此密切相关。

那时我们使用原生 .net oodbms 系统，主要是因为它允许我们做的是采用我们的对象模型并简单地在这里和那里添加一些与持久性相关的方法（-calls），我们就可以开始了。然而，随着时间的推移，我们遇到了越来越多的警告，非常糟糕、不可修复（在合理的时间范围内）的限制，迫使我们实施缓慢的解决方法，导致性能平庸，可扩展性问题即将出现，许可费用几乎增加了对我们来说是 5 倍，而我们没有任何变化（他们被大公司收购了）。

因此，我们目前开始在可扩展性/性能以及维护方面寻找长期解决方案。我们查看了其他“真正的”oodbms，并且总是遇到主要的破坏者，因此我们开始进一步研究，现在基本上正在考虑 ORM，希望这能让我们将大部分注意力集中在我们的对象上与 SQL 的争吵。

所以基本上这是我的问题：是否有人对 Microsoft 的实体框架或任何其他 .NET ORM 有任何实际经验，可以保持配置尽可能可维护，并在密切/高度相关的实体中表现良好？我们存储的数据量在任何方面都不是惊人的或广泛的（我们预计在未来 3 年内所有实体中总共有 10 万个实例）。

是否有人对 ORM 有任何想法/建议和/或从 oodbms 迁移到 rdbms 的经验？

4

2 回答 2

1

由于您有一个现有的对象模型并且您希望迁移到 ORM 解决方案，那么我会说 NHibernate 肯定是一个不错的选择。原因如下：

  1. 您不必对域模型类进行（m）任何添加/更改以支持持久性。NHibernate 在支持域模型中的持久性无知方面有很长的路要走，尽管您可能会发现您需要进行一些小的更改，例如将更多的方法/属性标记为虚拟，而不是其他方式。
  2. 映射现有对象模型后，您可以为数据库生成架构。这对于域驱动（或者只是对象模型优先）开发来说是一个巨大的节省时间。此功能通过 FluentConfiguration.ExposeConfiguration() 方法和 fluent NHibernate 或通过 hbm2ddl 工具和标准 NHibernate 映射文件来支持。当然，这也有助于提高可维护性——对对象模型的更改可以快速反映在数据库模式中。
  3. 使用流利的 NHibernate 进行映射有助于使初始映射非常快，因为您获得了自动完成和简化的映射模型。这也将有助于为您提供您正在寻找的可维护性 - 您的映射是在具有流畅 NHibernate 的代码中声明的，因此重构工具将相应地更改您的映射。您可能还会发现您可以使用 Fluent NHibernate 自动映射，并且在大多数情况下避免手动映射您的对象模型。

为此使用实体框架将更具挑战性。虽然实体框架在许多方面都是一个有能力的 ORM，但它不如 NHibernate 成熟，在这种情况下有几个原因，特别是为什么我认为它可能不是最佳选择：

  1. 您将不得不对现有对象模型进行大量更改以支持实体框架。如果您想使用当前提供的实体框架工具，您可能需要将代码迁移到生成的部分类，这些类继承自 EntityObject 实体框架基类。根据您现有的对象模型，此继承要求对您来说可能是也可能不是问题。您可以通过在代码中支持某些接口来避免这种情况，但这并不重要，我认为您将失去很多用于管理映射的内置工具支持。
  2. 您几乎肯定需要手动创建数据库模式。对于大小合适的对象模型，这通常不是一项微不足道的任务。
  3. 实体框架不支持开箱即用的透明延迟加载。我确信透明延迟加载是您习惯使用 OODBMS 的东西，并且大多数其他 ORM（当然包括 NHibernate）都支持它，但是对于实体框架，您会发现您需要显式地 .Load() 相关对象（父子关系），然后再在代码中引用它们。有解决方法（例如this one），但它不是内置功能。

总的来说，在我看来，对于对象优先的开发，或者你试图利用现有的对象模型，NHIbernate 是一个更好的选择。对于以数据为中心的开发，实体框架（或 linq to sql 甚至 subsonic）成为更可行的选择。

您可能还想评估诸如Lightspeed之类的商业 ORM 产品——我自己对这个特定工具的经验很少（当有很好的免费替代品时，客户通常反对为 ORM 付费），但它受到高度重视。

于 2009-04-15T10:44:01.820 回答
0

我对 OODBMS 没有任何经验，但我在 NHibernate + MS SQL Server 方面的经验在一对多、多对一和多对多关系的强制和级联更改方面非常积极。

您使用的是什么 OODBMS 工具？OODBMS -> RDBMS 迁移工具可能存在，但我不知道。

于 2009-04-13T10:55:17.007 回答