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

发布于 2024-07-16 15:35:14 字数 654 浏览 15 评论 0原文

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

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

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

御守 2024-07-23 15:35:14

由于您已经有一个现有的对象模型并且您正在寻求迁移到 ORM 解决方案，那么我认为 NHibernate 肯定是一个不错的选择。原因如下：

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

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

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

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

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

As you have an existing object model and you are looking to migrate to an ORM solution then I would say NHibernate would certainly be a good choice. Here's why:

You won't have to make (m)any additions / changes to your domain model classes to support persistence. NHibernate goes a long way towards supporting persistence ignorance in your domain model, although you may find you need make some minor changes such as marking more methods / properties as virtual than you otherwise would for example.
After mapping your existing object model, you can generate the schema for your database. This is a huge time saver for domain driven (or just object-model first) development. This functionality is supported via the FluentConfiguration.ExposeConfiguration() method with fluent NHibernate or via the hbm2ddl tool with standard NHibernate mapping files. This also helps, of course, with maintainability - changes to your object model can be quickly reflected in your database schema.
Using fluent NHibernate for mapping helps to make the initial mapping quite fast as you get autocomplete and a simplified mapping model. This will also help to give you the maintainability you are looking for - your mapping is declared in code with fluent NHibernate, so refactoring tools will change your mapping accordingly. You may also find that you can use Fluent NHibernate automapping and avoid manually mapping your object model for the most part.

Using Entity Framework for this will be more challenging. While entity framework is a capable ORM in many respects, it is not as mature as NHibernate and there are a few reasons in this case specifically why I think it's probably not the best choice:

You will have to make a lot of changes to your existing object model to support Entity Framework. If you want to use the currently supplied tools for entity framework you will probably need to migrate your code to generated partial classes which inherit from the EntityObject entity framework base class. This inheritance requirement may or may not be a problem for you depending on your existing object model. You could avoid this by supporting some interfaces in your code but this is non-trivial and I think you will lose a lot of the built in tooling support for managing your mappings.
You will almost certainly need to manually create the database schema. With a good sized object model this is typically not an insignificant task.
The entity framework does not support transparent lazy loading out of the box. I'm sure transparent lazy loading is something you are used to with an OODBMS, and it is supported by most other ORM's (including NHibernate of course), but with entity framework you will find that you need to explicitly .Load() related objects (both parent and child relationships) before you reference them in your code. There are workarounds for this (e.g. this one), but it's not a built-in feature.

Overall, in my opinion, for object-first development, or where you are trying to leverage an existing object model, NHIbernate is a better choice. For data-centric developments, the Entity Framework (or linq to sql or even subsonic) become more viable choices.

You may also want to evaluate commercial ORM offerings such as Lightspeed - I have little experience with this particular tool myself (customers generally object to paying for an ORM when there are good free alternatives) but it is highly regarded.

回复收藏 0 原文