从“本机”OODBMS迁移到ORM（实体框架/ SQL Server）

Question

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

当时我们使用原生的.net oodbms系统基本上是因为它允许我们做的是采用我们的对象模型，只是在这里和那里添加一些与持久性相关的方法（-calls），我们已经准备好了。然而，随着时间的推移，我们遇到越来越多的警告，非常糟糕，不可修复（在合理的时间范围内）限制，迫使我们实施缓慢的解决方案，导致平庸的性能和可扩展性问题，并且许可证费用几乎增加了因为我们没有变化（他们被大公司收购）。我们的因素为5。

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

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

有没有人对ORM和/或从oodbms迁移到rdbms的经历有什么想法/建议？

Answer 1

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

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

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

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

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

   您可能还想评估商业ORM产品，例如Lightspeed - 我自己对这个特定工具几乎没有经验（客户通常反对在有好的免费替代品的情况下支付ORM）但是它受到高度重视

Answer 2

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

您使用的是什么OODBMS工具？有可能OODBMS - ＆gt;存在RDBMS迁移工具，但我不知道任何。