对不同 OR 映射框架的抽象
我今天产品的数据访问层使用Hibernate作为OR映射框架。将来希望使用其他框架，例如iBatis。
- 在这些 OR 映射框架之上设计这样一个抽象层的最佳方法是什么？
- 现在有这样的框架吗？
- 我想设计这样一个系统，通过简单的配置更改，我应该能够在这些 OR 框架之间切换。
The Data access layer of my product today uses Hibernate as the OR mapping framework.In future would like to use other frameworks like iBatis.
- What is the best way to design such an abstraction layer on top of these OR mapping frameworks ?
- Is there any such framework already available ?
- I want to design such a system where with simple configuration changes I should be able to switch between these OR frameworks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为在 hibernate / ibatis 之上添加抽象没有意义。它们是完全不同的框架 - 即使您能够创建一个通用的 api - 它也会忽略元数据部分（您的代码更依赖于它）。您应该认真思考为什么需要它以及它会是什么样子。 人们已经在抱怨太多的抽象层次 - 添加更多的抽象层次只会让事情变得更加困难。
更好的解决方案是将大部分域逻辑与持久性/事务/安全性等隔离（域驱动设计）。这样，如果您必须更改其中一个应用程序逻辑的实现，您也许能够保留应用程序逻辑的重要部分。
看看 spring-data 它与您正在寻找的抽象类型不同。
I don't think adding an abstraction on top of hibernate / ibatis makes sense. They are quite different frameworks - even if you are able to create a common api - it will leave out the meta-data part (on which your code is much more dependent on). You should think really hard about why you need it and what it will look like. Already people are complaining about too many levels of abstractions - adding more only makes things more difficult.
A better solution would be to isolate most of your domain logic from depending on the persistence / transaction / security etc (Domain Driven Design). That way you might be able to preserve the important parts of the application logic if you have to change the implementation of one of them.
Take a look at spring-data it is different than the kind of abstraction that you are looking for.
问题是 iBatis 不是 ORM 框架，而 Hibernate 是。 iBatis 的要点是将具体的 SQL 语句映射到对象，而 Hibernate 试图以更抽象的方式解决对象关系映射（和不匹配）。
几年前，Hibernate 核心功能的子集已标准化为 JPA。以 JPA 方式做事是有意义的（因此您可以切换 JPA 供应商 - Hibernate、EclipseLink、ObjectDB）。
然而，在不同的方法（例如 Hibernate 与 iBatis）之上构建一些抽象并没有多大意义。
The problem is that iBatis is not ORM framework, while Hibernate is. Point of iBatis is to map concrete SQL statements to objects, while Hibernate tries to solve object-relational mapping (and mismatch) in more abstract way.
Few years ago, subset of core features of Hibernate has been standardized to JPA. It makes sense to do things JPA-way (so you can switch JPA vendor - Hibernate, EclipseLink, ObjectDB).
However, it doesn't make much sense building some abstraction on top of different approaches (like Hibernate vs iBatis).
首先，我绝对同意 Xorty 关于 iBatis 与 Hibernate 框架的回复。
除了一件事。您可以考虑在 iBatis、Hibernate 之间切换。
我建议您阅读《iBatis In Action》一书，第 10、11 章。您会发现其中有一个 iBatis 配置示例，可让您通过 DAO 模式及其实现来配置/使用 iBatis 和 Hibernate通过 iBatis sql 映射文件、Hibernate 和 JDBC。
First, I absolutely agree with Xorty's reply concerning iBatis vs. Hibernate frameworks.
Except one thing. You may consider switching between iBatis, Hibernate.
I would recommend you to read
iBatis In Actionbook, chapters 10, 11. You'll find there an example of iBatis configuration that let you to configure/use both iBatis and Hibernate with DAO pattern and its implementations by iBatis sql map files, Hibernate and JDBC.