普通旧 Java 对象 (POJO) 是什么意思?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/3326319/
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
What is meaning of Plain Old Java Object (POJO)?
提问by Nikit Batale
What does the term Plain Old Java Object (POJO)mean? I couldn't find anything explanatory enough.
术语普通旧 Java 对象 (POJO)是什么意思?我找不到任何足够的解释。
POJO's Wikipedia pagesays that POJO is an ordinary Java Object and not a special object. Now, what makes or what doesn't make and object special in Java?
POJO 的维基百科页面说 POJO 是一个普通的 Java 对象,而不是一个特殊的对象。现在,什么使 Java 中的对象变得特殊或不特殊?
The above page also says that a POJO should not have to extend prespecified classes, implement prespecified Interfaces or contain prespecified Annotations. Does that also mean that POJOs are not allowed to implement interfaces like Serializable
, Comparable
or classes like Applets or any other user-written Class/Interfaces?
上面的页面还说 POJO 不应该扩展预先指定的类、实现预先指定的接口或包含预先指定的注解。这是否也意味着不允许 POJO 实现像 Applet 这样的接口Serializable
,Comparable
或者像 Applet这样的类或任何其他用户编写的类/接口?
Also, does the above policy (no extending, no implementing) means that we are not allowed to use any external libraries?
另外,上述政策(不扩展,不实施)是否意味着我们不允许使用任何外部库?
Where exactly are POJOs used?
POJO 究竟在哪里使用?
EDIT:To be more specific, am I allowed to extend/implement classes/interfaces that are part of the Java or any external libraries?
编辑:更具体地说,我是否允许扩展/实现属于 Java 或任何外部库的类/接口?
回答by Carl Smotricz
Plain Old Java Object :)
普通的旧 Java 对象 :)
Well, you make it sound like those are all terrible restrictions.
好吧,你说得好像这些都是可怕的限制。
In the usual context where POJO is/are used, it's more like a benefit:
在使用 POJO 的通常情况下,它更像是一个好处:
It means that whatever library/API you're working with is perfectly willing to work with Java objects that haven't been doctored or manhandled in any way, i.e. you don't have to do anything special to get them to work.
这意味着您正在使用的任何库/API 都非常愿意使用没有以任何方式篡改或粗暴处理的 Java 对象,即您不必做任何特殊的事情来让它们工作。
For example, the XStream XML processor will (I think) happily serialize Java classes that don't implement the Serializable
interface. That's a plus! Many products that work with data objects used to force you to implement SomeProprietaryDataObject
or even extend an AbstractProprietaryDataObject
class. Many libraries will expect bean behavior, i.e. getters and setters.
例如,XStream XML 处理器将(我认为)愉快地序列化没有实现Serializable
接口的Java 类。这是一个加分项!许多使用数据对象的产品过去常常迫使您实现SomeProprietaryDataObject
甚至扩展一个AbstractProprietaryDataObject
类。许多库会期望 bean 行为,即 getter 和 setter。
Usually, whatever works with POJOs will also work with not-so-PO-JO's. So XStream will of course also serialize Serializable classes.
通常,适用于 POJO 的任何内容也适用于不那么 PO-JO 的。所以 XStream 当然也会序列化 Serializable 类。
回答by DVK
POJO is a Plain Old Java Object - as compared to something needing Enterprise Edition's (J2EE) stuff (beans etc...).
POJO 是一个普通的旧 Java 对象 - 与需要企业版 (J2EE) 的东西(bean 等)相比。
POJO is not really a hard-and-fast definition, and more of a hand-wavy way of describing "normal" non-enterprise Java Objects. Whether using an external library or framework makes an object POJO or not is kind of in the eye of the beholder, largely depending on WHAT library/framework, although I'd venture to guess that a framework would make something less of a POJO
POJO 并不是一个真正的硬性定义,而是一种描述“正常”非企业 Java 对象的手动方式。使用外部库或框架是否使对象成为 POJO 是旁观者眼中的,很大程度上取决于 WHAT 库/框架,尽管我冒昧地猜测框架会减少 POJO
回答by Benjamin
Usage of the term implies what it's supposed to tell you. If, for example, a dependency injection framework tells you that you can inject a POJO into any other POJO they want to say that you do not have to do anything special: there is no need to obey any contracts with your object, implement any interfaces or extend special classes. You can just use whatever you've already got.
该术语的使用意味着它应该告诉你什么。例如,如果一个依赖注入框架告诉你你可以将一个 POJO 注入到任何其他 POJO 中,他们想说你不需要做任何特别的事情:不需要遵守与你的对象的任何契约,实现任何接口或扩展特殊类。你可以使用你已经拥有的任何东西。
UPDATETo give another example: while Hibernate can map any POJO (any object you created) to SQL tables, in Core Data (Objective C on the iPhone) your objects have to extend NSManagedObject in order for the system to be able to persist them to a database. In that sense, Core Data cannot work with any POJO (or rather POOCO=PlainOldObjectiveCObject) while Hibernate can. (I might not by 100% correct re Core Data since I just started picking it up. Any hints / corrections are welcome :-) ).
更新再举一个例子:虽然 Hibernate 可以将任何 POJO(您创建的任何对象)映射到 SQL 表,但在 Core Data(iPhone 上的目标 C)中,您的对象必须扩展 NSManagedObject 以便系统能够将它们持久化到一个数据库。从这个意义上说,Core Data 不能与任何 POJO(或者更确切地说 POOCO=PlainOldObjectiveCObject)一起工作,而 Hibernate 可以。(我可能不会 100% 正确地重新使用 Core Data,因为我刚开始拿起它。欢迎任何提示/更正:-))。
回答by Grant Crofton
According to Martin Fowler, he and some others came up with it as a way to describe something which was a standard class as opposed to an EJB etc.
根据 Martin Fowler 的说法,他和其他一些人提出了它作为一种描述标准类而不是 EJB 等的方法。
回答by Peter Lawrey
The whole point of a POJO is simplicity and you appear to be assuming its something more complicated than it appears.
POJO 的全部意义在于简单,而且您似乎假设它比看起来更复杂。
If a library supports a POJO, it implies an object of any class is acceptible. It doesn't mean the POJO cannot have annotations/interface or that they won't be used if they are there, but it is not a requirement.
如果库支持 POJO,则意味着任何类的对象都是可接受的。这并不意味着 POJO 不能有注释/接口,或者如果它们在那里就不会被使用,但这不是必需的。
IMHO The wiki-page is fairly clear. It doesn't say a POJO cannot have annotations/interfaces.
恕我直言,维基页面相当清晰。这并不是说 POJO 不能有注释/接口。
回答by Kanagavelu Sugumar
Plain Old Java ObjectThe name is used to emphasize that a given object is an ordinary Java Object, not a special object such as those defined by the EJB 2 framework.
Plain Old Java Object该名称用于强调给定的对象是一个普通的 Java 对象,而不是像 EJB 2 框架定义的那些特殊对象。
class A {}
class B extends/implements C {}
A 类 {}
B 类扩展/实现 C {}
Note: B is non POJO when C is kind of distributed framework class or ifc. e.g. javax.servlet.http.HttpServlet, javax.ejb.EntityBean or J2EE extn and not serializable/comparable. Since serializable/comparable are valid for POJO.
注意:当 C 是一种分布式框架类或 ifc 时,B 是非 POJO。例如 javax.servlet.http.HttpServlet、javax.ejb.EntityBean 或 J2EE extn 且不可序列化/可比较。由于可序列化/可比较对 POJO 有效。
Here A is simple object which is independent. B is a Special obj since B is extending/implementing C. So B object gets some more meaning from C and B is restrictive to follow the rules from C. and B is tightly coupled with distributed framework. Hence B object is not POJO from its definition.
这里A是独立的简单对象。B 是一个特殊的对象,因为 B 正在扩展/实现 C。所以 B 对象从 C 那里得到了更多的意义,而 B 限制了遵循 C 的规则。并且 B与分布式框架紧密耦合。因此 B 对象从其定义来看不是 POJO。
Code using class A object reference does not have to know anything about the type of it, and It can be used with many frameworks.
使用类 A 对象引用的代码不必知道它的类型,并且它可以与许多框架一起使用。
So a POJO should not have to 1) extend prespecified classes and 2) Implement prespecified interfaces.
所以 POJO 不应该 1) 扩展预先指定的类和 2) 实现预先指定的接口。
JavaBean is a example of POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods that follow a simple naming convention.
JavaBean 是可序列化的 POJO 示例,具有无参数构造函数,并允许使用遵循简单命名约定的 getter 和 setter 方法访问属性。
POJO purely focuses on business logic and has no dependencies on (enterprise) frameworks.
It means it has the code for business logic but how this instance is created, Which service(EJB..) this object belongs to and what are its special characteristics( Stateful/Stateless) it has will be decided by the frameworks by using external xml file.
POJO 纯粹关注业务逻辑,不依赖(企业)框架。这意味着它具有业务逻辑的代码,但是如何创建该实例,该对象属于哪个服务(EJB ..)以及它具有哪些特殊特性(有状态/无状态)将由框架通过使用外部 xml 来决定文件。
Example 1: JAXB is the service to represent java object as XML; These java objects are simple and come up with default constructor getters and setters.
例 1:JAXB 是将 java 对象表示为 XML 的服务;这些 java 对象很简单,并提供了默认的构造函数 getter 和 setter。
Example 2: Hibernate where simple java class will be used to represent a Table. columns will be its instances.
示例 2:Hibernate,其中将使用简单的 java 类来表示表。列将是它的实例。
Example 3: REST services. In REST services we will have Service Layer and Dao Layer to perform some operations over DB. So Dao will have vendor specific queries and operations. Service Layer will be responsible to call Which DAO layer to perform DB operations. Create or Update API(methods) of DAO will be take POJOs as arguments, and update that POJOs and insert/update in to DB. These POJOs (Java class) will have only states(instance variables) of each column and its getters and setters.
示例 3:REST 服务。在 REST 服务中,我们将有 Service Layer 和 Dao Layer 来对 DB 执行一些操作。因此,Dao 将具有特定于供应商的查询和操作。Service Layer 将负责调用哪个 DAO 层来执行 DB 操作。创建或更新 DAO 的 API(方法)将以 POJO 作为参数,并更新该 POJO 并插入/更新到数据库中。这些 POJO(Java 类)将只有每列及其 getter 和 setter 的状态(实例变量)。
In practice, some people find annotations elegant, while they see XML as verbose, ugly and hard to maintain, yet others find annotations pollute the POJO model. Thus, as an alternative to XML, many frameworks (e.g. Spring, EJB and JPA) allow annotations to be used instead or in addition to XML:
在实践中,有些人认为注释很优雅,而他们认为 XML 冗长、丑陋且难以维护,而另一些人则认为注释污染了 POJO 模型。因此,作为 XML 的替代方案,许多框架(例如 Spring、EJB 和 JPA)允许使用批注代替 XML 或除 XML 之外使用:
Advantages:
Decoupling the application code from the infrastructure frameworks is one of the many benefits of using POJOs. Using POJOs future proofs your application's business logic by decoupling it from volatile, constantly evolving infrastructure frameworks. Upgrading to a new version or switching to a different framework becomes easier and less risky. POJOs also make testing easier, which simplifies and accelerates development. Your business logic will be clearer and simpler because it won't be tangled with the infrastructure code
优点:
将应用程序代码与基础架构框架解耦是使用 POJO 的众多好处之一。使用 POJO 可以通过将应用程序的业务逻辑与易变的、不断发展的基础架构框架解耦来证明应用程序的业务逻辑。升级到新版本或切换到不同的框架变得更容易且风险更小。POJO 还使测试更容易,从而简化并加速了开发。你的业务逻辑会更清晰、更简单,因为它不会和基础设施代码纠缠在一起
回答by Sandeep Kumar
A Plain Old Java Object (POJO) that contains all of the business logic for your extension.
包含扩展的所有业务逻辑的普通旧 Java 对象 (POJO)。
Exp. Pojo which contains a single method
经验。包含单个方法的 Pojo
public class Extension {
public static void logInfo(String message) {
System.out.println(message);
}
}
回答by Ali Dehghani
What does the term Plain Old Java Object (POJO) mean?
普通旧 Java 对象 (POJO) 是什么意思?
POJOwas coined by Martin Fowler, Rebecca Parsons and Josh Mackenzie when they were preparing for a talk at a conference in September 2000. Martin Fowler in Patterns of Enterprise Application Architectureexplains how to implement a Domain Modelpattern in Java. After enumerating some of disadvantages of using EJB Entity Beans:
POJO是由 Martin Fowler、Rebecca Parsons 和 Josh Mackenzie 在 2000 年 9 月的一次会议上准备演讲时创造的。Martin Fowler 在Patterns of Enterprise Application Architecture 中解释了如何在 Java 中实现领域模型模式。在列举了使用EJB Entity Beans 的一些缺点之后:
There's always a lot of heat generated when people talk about developing a Domain Model in J2EE. Many of the teaching materials and introductory J2EE books suggest that you use entity beans to develop a domain model, but there are some serious problems with this approach, at least with the current (2.0) specification.
Entity beans are most useful when you use Container Managed Persistence (CMP)...
Entity beans can't be re-entrant. That is, if you call out from one entity bean into another object, that other object (or any object it calls) can't call back into the first entity bean...
...If you have remote objects with fine-grained interfaces you get terrible performance...
To run with entity beans you need a container and a database connected. This will increase build times and also increase the time to do test runs since the tests have to execute against a database. Entity beans are also tricky to debug.
当人们谈论在 J2EE 中开发领域模型时,总会产生很多热议。许多教材和 J2EE 介绍书籍都建议您使用实体 bean 来开发域模型,但是这种方法存在一些严重的问题,至少在当前的 (2.0) 规范中是这样。
当您使用容器管理持久性 (CMP) 时,实体 bean 最有用...
实体 bean 不能重入。也就是说,如果您从一个实体 bean 调用到另一个对象,则该其他对象(或它调用的任何对象)无法回调到第一个实体 bean 中......
...如果你有带有细粒度接口的远程对象,你的性能会很差......
要使用实体 bean 运行,您需要一个容器和一个连接的数据库。这将增加构建时间并增加执行测试运行的时间,因为测试必须针对数据库执行。实体 bean 也很难调试。
As an alternative, he proposed to use Regular Java Objectsfor Domain Model implementation:
作为替代方案,他建议使用常规 Java 对象进行领域模型实现:
The alternative is to use normal Java objects, although this often causes a surprised reaction—it's amazing how many people think that you can't run regular Java objects in an EJB container. I've come to the conclusion that people forget about regular Java objects because they haven't got a fancy name. That's why, while preparing for a talk in 2000, Rebecca Parsons, Josh Mackenzie, and I gave them one: POJOs (plain old Java objects). A POJO domain model is easy to put together, is quick to build, can run and test outside an EJB container, and is independent of EJB (maybe that's why EJB vendors don't encourage you to use them).
另一种方法是使用普通的 Java 对象,尽管这通常会引起令人惊讶的反应 — 令人惊讶的是,有多少人认为您不能在 EJB 容器中运行普通的 Java 对象。我得出的结论是人们忘记了常规 Java 对象,因为它们没有一个花哨的名字。这就是为什么在准备 2000 年的演讲时,Rebecca Parsons、Josh Mackenzie 和我给了他们一个:POJO(普通的旧 Java 对象)。POJO 域模型易于组合、快速构建、可以在 EJB 容器之外运行和测试,并且独立于 EJB(也许这就是 EJB 供应商不鼓励您使用它们的原因)。