Plain Old Java Object（POJO）是什么意思？

Question 1

是什么术语普通Java对象（POJO）是什么意思？我找不到足够的解释。

POJO的Wikipedia页面上说POJO是一个普通的Java对象，而不是一个特殊的对象。现在，Java的特殊之处是什么？

上面的页面还说，POJO不必扩展预定类，实现预定接口或包含预定注释。这是否还意味着不允许POJO实现诸如的接口Serializable，Comparable或诸如Applets的类或任何其他用户编写的Class / Interfaces？

另外，上述政策（不扩展，不实施）是否表示不允许我们使用任何外部库？

POJO到底在哪里使用？

编辑：更具体地说，我是否允许扩展/实现属于Java或任何外部库的类/接口？

Question 2

普通的旧Java对象该名称用来强调给定对象是普通的Java对象，而不是EJB 2框架定义的特殊对象。

A类{}
B类扩展/实现C {}

注意：当C是一种分布式框架类或ifc时，B是非POJO。例如javax.servlet.http.HttpServlet，javax.ejb.EntityBean或J2EE extn，并且不可序列化/可比较。由于可序列化/可比较对POJO有效。

这里A是独立的简单对象。B是B的特殊对象，因为B正在扩展/实现C。因此B对象从C获得更多含义，并且B严格遵循C的规则。B与分布式框架紧密耦合。因此，从其定义来看，B对象不是POJO。

使用类的代码对象引用不必知道其类型，它可以与许多框架一起使用。

因此，POJO不必1）扩展预定的类和2）实现预定的接口。

JavaBean是POJO的示例，它是可序列化的，具有无参数构造函数，并允许使用遵循简单命名约定的getter和setter方法访问属性。

POJO纯粹专注于业务逻辑，不依赖（企业）框架。这意味着它具有用于业务逻辑的代码，但是该实例的创建方式，该对象属于哪个服务（EJB ..）以及它具有哪些特殊特征（有状态/无状态），将由框架使用外部xml来确定。文件。

示例1：JAXB是将Java对象表示为XML的服务；这些java对象很简单，并带有默认的构造函数getter和setters。

示例2：Hibernate，其中将使用简单的Java类来表示Table。列将为其实例。

示例3：REST服务。在REST服务中，我们将具有服务层和Dao层，以通过DB执行一些操作。因此，Dao将具有特定于供应商的查询和操作。服务层将负责调用哪个DAO层来执行数据库操作。DAO的创建或更新API（方法）将以POJO为参数，并更新该POJO并插入/更新到DB中。这些POJO（Java类）将仅具有每列的状态（实例变量）以及其getter和setter。

在实践中，有些人认为注释优雅，而他们却认为XML冗长，丑陋且难以维护，而另一些人则发现注释污染了POJO模型。因此，作为XML的替代方案，许多框架（例如Spring，EJB和JPA）允许使用注解代替XML或在XML之外使用注解：

优点：
将应用程序代码与基础架构框架分离是使用POJO的众多好处之一。使用POJO可以通过将应用程序与不稳定的，不断发展的基础架构框架分离开来，从而证明您的应用程序的业务逻辑。升级到新版本或切换到其他框架变得更容易，风险也更低。POJO还使测试更加容易，从而简化并加速了开发。您的业务逻辑将更加清晰和简单，因为它不会与基础结构代码纠缠在一起

参考：Wiki source2

Question 3

根据Martin Fowler的说法，他和其他一些人提出了一种将其描述为标准类而不是EJB等的方式。

Question 4

该术语的用法暗示了它应该告诉您的内容。例如，如果依赖注入框架告诉您可以将POJO注入任何其他POJO，他们想说您不必做任何特殊的事情：无需遵守与对象的任何契约，则实现任何接口或扩展特殊课程。您可以使用已经拥有的任何东西。

更新再举一个例子：虽然Hibernate可以将任何POJO（您创建的任何对象）映射到SQL表，但是在Core Data（iPhone上的目标C）中，您的对象必须扩展NSManagedObject，以便系统能够将其持久化到数据库。从这种意义上讲，Core Data无法与任何POJO（或更确切地说，POOCO = PlainOldObjectiveCObject）一起使用，而Hibernate则可以。（由于我刚开始使用Core Data，我可能不会100％正确地修改核心数据。欢迎任何提示/更正:-)）。

Question 5

普通的旧Java对象:)

好吧，听起来好像这些限制都是可怕的。

在通常使用POJO的情况下，它更像是一种好处：

这意味着您正在使用的任何库/ API都非常愿意与未经任何方式篡改或处理的Java对象一起使用，即，您无需执行任何特殊操作即可使其工作。

例如，XStream XML处理器（我认为）将愉快地序列化未实现该Serializable接口的Java类。这是一个加号！许多与数据对象一起使用的产品通常用来强迫您实现SomeProprietaryDataObject甚至扩展一个AbstractProprietaryDataObject类。许多库都会期望bean的行为，即getter和setter。

通常，与POJO一起使用的任何内容也将与非PO-JO一起使用。因此，XStream当然还将序列化Serializable类。

Question 6

POJO是一个普通的Java对象-与需要Enterprise Edition（J2EE）的东西（beans等）相比。

POJO并不是一个严格的定义，而是一种描述“常规”非企业Java对象的手工方式。旁观者认为，使用外部库还是使用框架是否使对象成为POJO，很大程度上取决于WHAT库/框架，尽管我敢冒险猜测框架将使POJO少一些

Question 7

POJO的全部重点是简单性，您似乎在假设它比看上去复杂。

如果库支持POJO，则表示任何类的对象都是可接受的。这并不意味着POJO不能具有注释/接口，或者如果它们存在就不会被使用，但这不是必需的。

恕我直言，维基页面相当清晰。它并不表示POJO不能具有注释/接口。

Question 8

一个普通的旧Java对象（POJO），其中包含扩展的所有业务逻辑。

经验 Pojo包含一个方法

public class Extension {
   public static void logInfo(String message) {
      System.out.println(message);
   }
}

Question 9

普通旧Java对象（POJO）是什么意思？

POJO是由Martin Fowler，Rebecca Parsons和Josh Mackenzie在2000年9月的一次会议上准备演讲时创造的。企业应用程序体系结构模式中的Martin Fowler解释了如何在Java中实现域模型模式。在列举了使用EJB实体Bean的一些缺点之后：

当人们谈论在J2EE中开发域模型时，总是会产生大量热量。许多教学材料和J2EE入门书籍都建议您使用实体bean开发域模型，但是这种方法至少在当前的（2.0）规范中存在一些严重的问题。

使用容器管理的持久性（CMP）时，实体Bean最有用。

实体bean不能重入。也就是说，如果您从一个实体Bean调出另一个对象，则另一个对象（或它调用的任何对象）将无法调回到第一个实体Bean中。

...如果您的远程对象具有细粒度的接口，您将获得可怕的性能...

要与实体bean一起运行，您需要连接一个容器和一个数据库。由于测试必须针对数据库执行，因此这将增加构建时间，并增加测试运行时间。实体bean调试起来也很棘手。

作为替代方案，他提议将常规Java对象用于域模型实现：

替代方法是使用普通Java对象，尽管这通常会引起意外的反应-令人惊讶的是，有很多人认为您无法在EJB容器中运行常规Java对象。我得出的结论是，人们忘记了常规的Java对象，因为他们没有一个好听的名字。因此，在准备2000年的演讲时，丽贝卡·帕森斯（Rebecca Parsons），乔什·麦肯齐（Josh Mackenzie）和我给了他们一个：POJO（普通的Java对象）。POJO域模型易于组合，易于构建，可以在EJB容器外部运行和测试，并且独立于EJB（也许这就是EJB供应商不鼓励您使用它们的原因）。