java 什么时候使用 Hibernate/JPA/Toplink？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/122571/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
When to use Hibernate/JPA/Toplink?
提问by GBa
Right now I'm making an extremely simple website- about 5 pages. Question is if it's overkill and worth the time to integrate some sort of database mapping solution or if it would be better to just use plain old JNDI. I'll have maybe a dozen things I need to read/write from the database. I guess I have a basic understanding of these technologies but it would still take a lot of referring to the documentation. Anyone else faced with the decision before?
现在我正在制作一个非常简单的网站 - 大约 5 页。问题是是否值得花时间集成某种数据库映射解决方案，或者只使用普通的旧 JNDI 会更好。我可能需要从数据库中读取/写入十几种东西。我想我对这些技术有基本的了解，但仍然需要大量参考文档。其他人之前面临过这个决定吗？
EDIT: Sorry, I should've specified JNDI to lookup the DB connection and JDBC to perform the operations.
编辑：抱歉，我应该指定 JNDI 来查找数据库连接和 JDBC 来执行操作。
回答by OscarRyz
Short answer: It depends on the complexity you want to support.
简短回答：这取决于您要支持的复杂性。
Long answer:
长答案：
First of all, ORM ( object relational mapping - database mapping as you call it - ) and JNDI ( Java Naming and Directory Interfaces ) are two different things.
首先，ORM（对象关系映射-您称之为数据库映射-）和JNDI（Java 命名和目录接口）是两个不同的东西。
The first as you already know, is used to map the Database tables to classes and objects. The second is to provide a lookup mechanism for resources, they may be DataSources, Ejb, Queues or others.
如您所知，第一个用于将数据库表映射到类和对象。二是提供资源查找机制，可以是DataSources、Ejb、Queues等。
Maybe your mean "JDBC".
也许你的意思是“JDBC”。
Now as for your question: If it is that simple may be it wouldn't be necessary to implement an ORM. The number tables would be around 5 - 10 at most, and the operations really simple, I guess.
现在至于你的问题：如果它这么简单，可能就没有必要实现 ORM。数字表最多大约为 5 - 10，而且操作非常简单，我猜。
Probably using plain JDBC would be enough.
可能使用普通的 JDBC 就足够了。
If you use the DAO pattern you may change it later to support the ORM strategy if needed.
如果您使用 DAO 模式，您可以稍后更改它以在需要时支持 ORM 策略。
Like this: Say you have the Employee table
像这样：假设您有 Employee 表
You create the Employee.java with all the fields of the DB by hand ( it should not take too long ) and a EmployeeDaO.java with methods like:
您使用数据库的所有字段手动创建 Employee.java（不应花费太长时间）和一个 EmployeeDaO.java，其方法如下：
+findById( id ): Employee
+insert( Employee )
+update( Employee )
+delete( Employee )
+findAll():List<Employee>
And the implementation is quite straight forward:
实现非常简单：
select * from employee where id = ?
insert into employee ( bla, bla, bla ) values ( ? , ? , ? )
update etc. etc
When ( and If ) your application becomes too complex you may change the DAO implementation . For instance in the "select" method you change the code to use the ORM object that performs the operation.
当（和如果）您的应用程序变得过于复杂时，您可以更改 DAO 实现。例如，在“select”方法中，您更改代码以使用执行操作的 ORM 对象。
public Employee selectById( int id ) {
// Commenting out the previous implementation...
// String query = select * from employee where id = ?
// execute( query )
// Using the ORM solution
Session session = getSession();
Employee e = ( Employee ) session.get( Employee.clas, id );
return e;
}
This is just an example, in real life you may let the abstact factory create the ORM DAO, but that is offtopic. The point is you may start simple and by using the desing patterns you may change the implementation later if needed.
这只是一个例子，在现实生活中你可以让抽象工厂创建 ORM DAO，但那是离题的。关键是您可以从简单开始，通过使用设计模式，您可以在以后根据需要更改实现。
Of course if you want to learn the technology you may start rigth away with even 1 table.
当然，如果您想学习这项技术，您甚至可以从一张桌子开始。
The choice of one or another ( ORM solution that is ) depend basically on the technology you're using. For instance for JBoss or other opensource products Hibernate is great. It is opensource, there's a lot of resources where to learn from. But if you're using something that already has Toplink ( like the oracle application server ) or if the base is already built on Toplink you should stay with that framework.
选择一种或另一种（即 ORM 解决方案）基本上取决于您使用的技术。例如对于 JBoss 或其他开源产品，Hibernate 很棒。它是开源的，有很多资源可以学习。但是，如果您正在使用已经有 Toplink 的东西（例如 oracle 应用服务器），或者如果基础已经建立在 Toplink 上，您应该继续使用该框架。
By the way, since Oracle bought BEA, they said they're replacing Kodo ( weblogic peresistence framework ) with toplink in the now called "Oracle Weblogic Application Server".
顺便说一下，自从 Oracle 收购了 BEA，他们说他们正在用现在称为“Oracle Weblogic 应用服务器”中的 toplink 替换 Kodo（weblogic 持久性框架）。
I leave you some resources where you can get more info about this:
我给你留下了一些资源，你可以在其中获得更多信息：
在这本“企业应用程序架构模式”一书中，Martin Fowler 解释了在何处使用一种或另一种，这是目录。看看数据源架构模式与对象关系行为模式：
DAO（数据访问对象）是核心 J2EE 模式目录的一部分：
This is a starter tutorial for Hibernate:
这是 Hibernate 的入门教程：
The official page of Toplink:
Toplink官方页面：
Finally I "think" the good think of JPA is that you may change providers lately.
最后，我“认为”JPA 的好处在于您最近可能会更改提供程序。
Start simple and then evolve.
从简单开始，然后发展。
I hope this helps.
我希望这有帮助。
回答by ColinD
It does seem like it would be overkill for a very simple application, especially if you don't have plans to expand on it ever. However, it also seems like it could be worthwhile to use those with this simple application so that you have a better understanding of how they work for next time you have something that could use them.
对于一个非常简单的应用程序来说，这似乎有点矫枉过正，尤其是如果您没有计划对其进行扩展。但是，似乎值得将它们与这个简单的应用程序一起使用，以便您在下次拥有可以使用它们的东西时更好地了解它们的工作方式。
回答by Hank
Do you mean plain old JDBC? A small project might be a good opportunity to pick up one of the ORM frameworks, especially if you have the time.
你是说普通的 JDBC 吗？一个小项目可能是学习 ORM 框架之一的好机会，尤其是如果您有时间的话。
Without more information it's hard to provide a recommendation one way or another however.
但是，如果没有更多信息，就很难以一种或另一种方式提供建议。
回答by Brian Deterling
My rule of thumb is if it's read-only, I'm willing to do it in JDBC, although I prefer to use an empty Hibernate project with SQLQuery to take advantage of Hibernate's type mapping. Once I have to do writes, I go with Hibernate because it's so much easier to set a few attributes and then call save than to set each column individually. And when you have to start optimizing to avoid updates on unchanged objects, you're way better off with an OR/M and its dirty checking. Dealing with foreign key relationships is another sign that you need to map it once and then use the getters. The same logic would apply to Toplink, although unless they've added something like HQL in the 3 years since I used it, Hibernate would be much better for this kind of transition from pure SQL. Keep in mind that you don't have to map every object/table, just the ones where there's a clear advantage. In my experience, most projects that don't use an existing OR/M end up building a new one, which is a bad idea.
我的经验法则是，如果它是只读的，我愿意在 JDBC 中进行，尽管我更喜欢使用带有 SQLQuery 的空 Hibernate 项目来利用 Hibernate 的类型映射。一旦我必须进行写入，我就会使用 Hibernate，因为设置一些属性然后调用 save 比单独设置每一列要容易得多。当您必须开始优化以避免更新未更改的对象时，最好使用 OR/M 及其脏检查。处理外键关系是您需要映射一次然后使用 getter 的另一个标志。同样的逻辑也适用于 Toplink，尽管除非他们在我使用它的 3 年里添加了类似 HQL 的东西，否则 Hibernate 会更好地用于这种从纯 SQL 的转换。请记住，你不 不必映射每个对象/表，只映射那些有明显优势的对象/表。根据我的经验，大多数不使用现有 OR/M 的项目最终都会构建一个新的 OR/M，这是一个坏主意。
回答by S.Lott
The bestway to learn ORM is on a small project. Start on this project.
学习 ORM的最佳方式是在一个小项目中。开始这个项目。
Once you get the hang of it, you'll use ORM for everything.
一旦掌握了窍门，您将在所有事情上都使用 ORM。
There's nothing too small for ORM. After your first couple of projects, you'll find that you can't work any other way. The ORM mapping generally makes more sense than almost any other way of working.
对于 ORM 来说，没有什么太小了。在你的前几个项目之后，你会发现你不能以任何其他方式工作。ORM 映射通常比几乎任何其他工作方式都更有意义。
回答by Kalpesh Soni
Look at the various toplink guides here, they have intro, examples, scenarios etc
在这里查看各种顶级链接指南，它们有介绍、示例、场景等
