您是否会将 NHibernate 用于具有遗留数据库的项目，而该数据库部分超出了您的控制范围？
对我来说，目前的答案是：不，我会使用 iBatis，因为当数据库模型和对象模型不同步时，NHibernate 很痛苦。 如果我不能完全控制数据库，我最终会做很多工作。
我为什么要问？
好吧，首先：我从未使用过 NHibernate。 我只是从表面上知道这一点。 我已经了解了 iBatis 对于遗留数据库的优势。
第二：最近我和一个使用 Hibernate 的人进行了讨论（jep，Hibernate 之前没有“N”）。 他告诉我现在ORM框架已经相当先进了，提倡Hibernate。 由于我对NHibernate不感兴趣，所以没有跟踪最近的进展。
也许我是时候重新考虑我的答案了，或者不是？
For me the answer is currently: No, I would use iBatis, because NHibernate is a pain, when the database model and the object model are not in synch. If I don't have full control over the database I end up with a lot of work.
Why do I ask?
Well, first of all: I never used NHibernate. I just know it from the surface. I have read about the advantages of iBatis for legacy databases.
Second: Recently I had a discussion with someone who worked with Hibernate (jep, without 'N' before Hibernate). He told me that the ORM frameworks are now pretty advanced and advocated Hibernate. Since I was not interested in NHibernate, I didn't keep track of the recent developments.
Maybe I its time to rethink my answer, or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
iBatis 当然很容易将对象映射到遗留数据库系统。
最近，NHibernate 1.2 和 2.0 的功能集可能会让您重新思考 iBatis。
NHibernate 使用复合键，这在较旧的数据库中经常出现，它们并不总是令人愉快地使用，但对此有支持。
NHibernate 可以利用存储过程对实体以及数据库视图进行 CRUD 操作。
集合可以是自定义存储过程或 SQL 查询。 当外键关系不直接映射到另一端的主键时，集合可以使用 property-ref 属性。
其中一些功能可能会降低 nhibernate 的性能/功能，即使用 property-ref 进行延迟加载不起作用（根本不工作？），但大多数情况下都是有原因的。
其他要点：（与您的遗留数据库并不真正相关，但仍然可以帮助决定技术选择）
Nhibernate 社区似乎比 iBatis 丰富得多。 我在这两个列表中，并且与 iBatis 组相比，对 NHibernate 的支持量相当大。 所以支持应该更容易。
此外，NHibernate 的 contrib/3rd 方工具数量也在不断增加。 诸如 NHibernate Profiler、Nhibernate 查询分析器、NHibernate Contrib、Fluent NHibernate 等等。
也许您可以扩展一下您认为 iBatis 目前具有的优势。 NHibernate 最近确实非常活跃，并且获得了许多新功能，其中很多功能确实有助于遗留/难以修改的模式。
为了回答这个问题，是的，我们确实将 NHibernate 与遗留数据库一起使用，这些数据库具有糟糕的关系、复合键、损坏的关系。 我们还有少量基于iBatis的代码。 不过，我们不再编写任何 iBatis 代码。
iBatis is certainly easy to map objects to legacy database systems.
More recently NHibernate 1.2 and 2.0 have a feature set that may make you rethink iBatis.
NHibernate works with composite keys, which can occur frequently in older databases, they aren't always pleasant to work with but support is there for this.
NHibernate can utilise Stored Procedures for CRUD operations on entities, also database views.
Collections can be custom stored procedures or SQL queries. Collections can use the property-ref attribute when the Foreign Key relationship doesn't map directly to the Primary Key on the other side.
Some of these features may take away from the performance/power of nhibernate, ie Lazy Loading with property-ref doesn't work (at all?), but is most cases there are reasons for this.
Other points: (which aren't really related to your legacy database but still can help decide on a technology choice)
The Nhibernate community appears much richer than the iBatis. I'm on both lists and the volume of support for NHibernate is quite large compared to the iBatis group. So support should be easier.
Also there is a growing amount of contrib/3rd party tools for NHibernate. Things like The NHibernate Profiler, the Nhibernate Query Analyzer, NHibernate Contrib, Fluent NHibernate to name a few.
Perhaps you can expand on what advantages you believe iBatis currently has. NHibernate has certainly been quite active recently and has gained many new features, a lot of which do assist in legacy/hard to modify schemas.
And to answer the question, yes we do use NHibernate with legacy databases that have awful relationships, composite keys, broken relationships. We still also have a small amount of code based on iBatis. We no longer write any more iBatis code though.
是的，考虑 NHibernate。 这是黄金标准是有原因的。 我听说 iBATIS 支持疯狂的映射可能性，但是使用 NHibernate 的 IUserType 你可以映射任何东西，甚至是非常奇怪的列。
@Ahmad，ORM 的全部目的是防止对象和模式之间的紧密耦合。 如果你遇到这个问题，那你就做错了。
此外，NHibernate 还提供大量用于自定义查询、公式属性和存储过程的选项。 HQL 非常强大，Criteria 也很灵活。
我认为如果你不至少提高 NHibernate 的性能，你就会给你的客户带来伤害。
Yes, consider NHibernate. It's the gold standard for a reason. I have heard that iBATIS supports crazy mapping possibilities, but with NHibernate's IUserType you can map anything, even really strange columns.
@Ahmad, the entire point of ORM is to prevent a tight coupling between your objects and your schema. If you have this problem you're doing it wrong.
Also, with NHibernate there are plenty of options for custom queries, formula properties and stored procedures. HQL is extremely powerful and Criteria is flexible.
I think you'll be doing your clients a disservice if you don't at least spike NHibernate.
我一直在现有应用程序中使用 nHibernate。 我将它用于所有新的开发，我无意将现有的东西移植到那里，只是没有令人信服的理由，但对于项目中的新东西来说它效果很好。
如果您要移植代码，那么您应该能够更改数据库以更好地匹配您的域模型，而不会产生太大影响（取决于数据库的泄漏程度，即谁访问它）。 然而，更改域模型会影响应用程序。
I've been using nHibernate in an existing application. I use it for all new development, I have no intention of porting the existing stuff over either there just isn't a compelling reason but for new stuff on the project it works great.
If you are going to port the code over then you should be able to change the database to match better with your domain model, without much impact (depending on how leaky your database is ie who access it). Changing the domain model would impact the application however.