【问题标题】:Are these synonymous, a subset of each other or completely different?这些是同义词,彼此的子集还是完全不同?
【发布时间】:2011-03-14 06:41:08
【问题描述】:

问题标题中提到的概念在一定程度上是同义词吗?主要区别在哪里(上下文,结构,...),可以将一个视为另一个的子集吗?以下是来自 Wikipedia 的一些简短定义。

POJO(普通旧 Java 对象) Wikipedia

在计算软件中,POJO 是一种 普通旧 Java 对象的首字母缩写词。这 名称用于强调给定的 object 是一个普通的 Java 对象,而不是 一个特殊的对象,特别是 不是企业 JavaBean。术语 由马丁·福勒、丽贝卡创造 帕森斯和乔什·麦肯齐在 2000 年 9 月:

"We wondered why people were so against using regular objects in their
 systems and concluded that it was
 because simple objects lacked a fancy
 name. So we gave them one, and it's
 caught on very nicely."

Java Bean Wikipedia

JavaBeans 是可重用的软件 Java的组件可以是 在构建器中进行可视化操作 工具。实际上,它们是类 用Java编程编写 符合特定语言 习俗。他们习惯于 将许多对象封装成一个 对象(bean),以便它们可以 作为单个 bean 对象传递 而不是作为多个个体 对象。 JavaBean 是 Java 对象 是可序列化的,有一个空值 构造函数,并允许访问 使用 getter 和 setter 的属性 方法。

值对象 Wikipedia

数据传输对象 (DTO),以前 称为值对象或 VO,是 用于传输数据的设计模式 软件应用程序之间 子系统。 DTO 常用于 结合数据访问对象 从数据库中检索数据。

业务对象 Wikipedia

业务对象是一种类型 作为演员的可理解实体 在业务层内部 n层面向对象计算机 程序。

相关:

Difference between DTO, VO, POJO, JavaBeans? What is the difference between a JavaBean and a POJO? DDD: what's the use of the difference between entities and value objects?

【问题讨论】:

  • 您的具体问题是什么?无论如何,相关:stackoverflow.com/questions/1612334/…
  • 问题是使用其中一些作为同义词是否是错误的(就像我听说有些人那样)以及给定的分类是否可以被视为子集或另一个。

标签: java business-objects javabeans pojo value-objects


【解决方案1】:

并非所有这些分类都是相关的。这是我的理解:

  • POJO 就像它的名字所暗示的那样 - 一个普通的旧 Java 对象。它没有什么特别之处。当我们说一个对象是一个 POJO 时,这正是我们想要传达的。今天,大多数应用程序都在使用某些类型的底层框架,并且随着框架而来的是对与框架集成的对象的要求——对象必须实现一个接口或扩展一个类。当我们说一个对象是 POJO 时,我们的意思是说它只是一个普通的对象,不依赖于任何框架。

  • JavaBean 是一个 Java 类,它遵循您的问题中描述的某些约定。此类对象通常由某些框架强制执行,这些框架使用反射来找出对象的属性(可通过 getter/setter 访问)并操纵它们,例如bean 暴露给 JSP、Spring bean 等。JavaBeans 的好处是它们仍然是 POJO。尽管它们遵循某些约定,但这些约定不是由任何特定框架定义的,而是由 Sun Javabean 标准定义的,并且这些类仍然是纯 Java 类,与任何第三方框架的类或接口没有任何联系。

  • 业务对象是指代表您的业务领域实体的对象。这些通常驻留在您的业务层 - 所有业务逻辑所在的层。这些对象通常映射到持久性存储实体,例如表。这些对象可以是 POJO、JavaBean、EJB 等。

  • 值对象是一种设计模式。在一些小型 Web 应用程序中,您也可以选择在 Web 层中使用业务对象。但是,在较大的应用程序或 J2EE 应用程序中,您定义值对象以将信息从业务层移动到 Web 层。这就是为什么它们也被称为数据传输对象 (DTO)。这些对象通常仅具有 Web 层所需的属性,而将用于业务层消费的业务对象的属性留在后面。它们还可能具有在业务层中生成的“计算”属性。使用这种模式有助于分离业务层和 Web 层。

【讨论】:

    【解决方案2】:

    这是我的看法:

    1. 业务对象是一个通用术语 对于抽象的想法 代表你的问题。你可以 用任何语言实现它们。在 Java,您还有其他选择 make,因为它们可以是 POJO 或 EJB,可变或不可变。
    2. 值对象或 DTO 用于在层之间传送数据。它们通常是不可变的。它们可以实现为 POJO 或 Java Bean。将它们视为 POJO 的另一个子集。
    3. Java Bean 符合原始 Sun 规范。它们旨在提供一个接口,使它们能够轻松地插入到 VB 风格的 IDE 中。将这些视为 POJO 的子集。
    4. 人们有时会对 Java Bean 和 Enterprise Java Bean 之间的区别感到困惑。 Java Bean 是原始 Java 1.0 规范的一部分,旨在类似于 VB 组件(还记得“Bean Box”吗?)。 Enterprise Java Beans 是遵循的规范,描述了特殊的 Java 对象如何实现特定的接口以与 Java EE 应用程序服务器进行互操作。应用程序服务器是分布式组件架构的事务监视器,它将处理线程、持久性、池、对象生命周期、消息传递、命名等。EJB 是 Java 对象的一个​​非常特殊的子集,仅在 Java EE 应用程序的上下文中工作服务器。
    5. 可以实现 POJO 以符合 Java Bean 标准,但这不是必需的。任何 Java 对象都有资格作为 POJO。最初是为了将它们与 EJB 2.0 版区分开来,后者需要多个接口才能与 Java EE 应用服务器正确互操作。

    【讨论】:

      【解决方案3】:

      问题是使用其中一些作为同义词是否是错误的(就像我听说有些人那样),以及给定的分类是否可以被视为子集。

      将这些术语用作同义词是错误的。它们显然具有不同的含义。引用的定义(以及其他答案中提供的定义)清楚地说明了这一点。

      但是,如果使用许多(甚至全部)这些术语来描述相同的对象或对象通常是有效的。这完全是一个观点问题。即您要强调的对象的哪个方面。

      【讨论】:

      • 好的,如果这些术语有时被用作等价词是可以理解的。我已经添加了迄今为止发布的答案的综合。如果您觉得应该添加一些内容,请这样做。
      【解决方案4】:

      综合(来自给出的答案):

      • POJO:一个不依赖任何框架的普通对象。它可以适应 Java Bean 标准而不是这样的要求。
      • JavaBean:符合 Sun JavaBean 或 Java 1.0 规范的对象(参见“Bean box”)。它们最初的目的是提供一个接口,以便可以轻松地将它们插入 VB 风格的 IDE。可以被视为 POJO 的一个子集,并且保持独立于框架。它可以使用某些机制(例如反射)来访问属性。
      • 企业 Java Bean:这些不应与 Java Bean 混淆。随着版本 3.0 带来的简化,EJB 可以被视为等同于 POJO。 EJB 本身就是一个描述可以与 Java EE 服务器互操作的特殊 Java 对象的规范。服务器本身在分布式组件架构的上下文中充当事务监视器,处理诸如线程、持久性、池化、对象生命周期、消息传递和命名之类的事情。因此,可以将 EJB 视为一个非常特殊的子集,用于 Java EE 应用程序服务器。
      • 业务对象:有助于表示给定问题的理论概念或抽象概念。它代表业务领域实体并驻留在应用程序的业务层中。它们可以映射到持久性上下文中的实体。该对象可以是 POJO/JavaBean/EJB,并且可以是可变的或不可变的。
      • 值对象/数据传输对象:采用有助于分离业务层和 Web 层的设计模式。这是为了适应大型应用程序的上下文,其中对象可以在层之间传输(例如业务层和 Web 层)。它们通常本质上是不可变的,可以格式化为 POJO 或 Java Bean。一个特点是它们可以包含在业务层中生成的计算属性。

      P.S:标记为社区 wiki,因此请随时编辑。

      【讨论】:

      • 请务必注意,EJB 3.x POJO
      • 已更新。我只知道 EJB 3.0,所以我无法评论。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-10-08
      • 1970-01-01
      • 2011-04-09
      • 2014-08-12
      • 1970-01-01
      相关资源
      最近更新 更多