javabean

JavaBean是一个遵循Sun定义的JavaBean约定的类。维基百科对javabean有一个很好的总结:

JavaBeans are reusable software components for Java that can be manipulated visually in a builder tool. Practically, they are classes written in the Java programming language conforming to a particular convention. They are used to encapsulate many objects into a single object (the bean), so that they can be passed around as a single bean object instead of as multiple individual objects. A JavaBean is a Java Object that is serializable, has a nullary constructor, and allows access to properties using getter and setter methods. In order to function as a JavaBean class, an object class must obey certain conventions about method naming, construction, and behavior. These conventions make it possible to have tools that can use, reuse, replace, and connect JavaBeans. The required conventions are: The class must have a public default constructor. This allows easy instantiation within editing and activation frameworks. The class properties must be accessible using get, set, and other methods (so-called accessor methods and mutator methods), following a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties. The class should be serializable. This allows applications and frameworks to reliably save, store, and restore the bean's state in a fashion that is independent of the VM and platform. Because these requirements are largely expressed as conventions rather than by implementing interfaces, some developers view JavaBeans as Plain Old Java Objects that follow specific naming conventions.

POJO

普通旧Java对象或POJO最初是用来指定简单的轻量级Java对象的术语，它没有实现任何javax。ejb接口，而不是重量级的ejb 2。x(特别是实体bean，无状态会话bean在我看来并不是那么糟糕)。今天，这个词被用于任何简单的物体，没有额外的东西。维基百科在定义POJO方面做得很好:

POJO is an acronym for Plain Old Java Object. The name is used to emphasize that the object in question is an ordinary Java Object, not a special object, and in particular not an Enterprise JavaBean (especially before EJB 3). The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000: "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." The term continues the pattern of older terms for technologies that do not use fancy new features, such as POTS (Plain Old Telephone Service) in telephony, and PODS (Plain Old Data Structures) that are defined in C++ but use only C language features, and POD (Plain Old Documentation) in Perl. The term has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks. A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods. An Enterprise JavaBean is not a single class but an entire component model (again, EJB 3 reduces the complexity of Enterprise JavaBeans). As designs using POJOs have become more commonly-used, systems have arisen that give POJOs some of the functionality used in frameworks and more choice about which areas of functionality are actually needed. Hibernate and Spring are examples.

值对象

值对象或VO是一个对象，例如java.lang.Integer，它保存值(因此是值对象)。对于更正式的定义，我经常参考Martin Fowler对Value Object的描述:

In Patterns of Enterprise Application Architecture I described Value Object as a small object such as a Money or date range object. Their key property is that they follow value semantics rather than reference semantics. You can usually tell them because their notion of equality isn't based on identity, instead two value objects are equal if all their fields are equal. Although all fields are equal, you don't need to compare all fields if a subset is unique - for example currency codes for currency objects are enough to test equality. A general heuristic is that value objects should be entirely immutable. If you want to change a value object you should replace the object with a new one and not be allowed to update the values of the value object itself - updatable value objects lead to aliasing problems. Early J2EE literature used the term value object to describe a different notion, what I call a Data Transfer Object. They have since changed their usage and use the term Transfer Object instead. You can find some more good material on value objects on the wiki and by Dirk Riehle.

数据传输对象

数据传输对象(DTO)是EJB引入的一种(反)模式。与其在ejb上执行许多远程调用，其思想是将数据封装在一个可以通过网络传输的值对象中:数据传输对象。维基百科对数据传输对象有一个很好的定义:

Data transfer object (DTO), formerly known as value objects or VO, is a design pattern used to transfer data between software application subsystems. DTOs are often used in conjunction with data access objects to retrieve data from a database. The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behaviour except for storage and retrieval of its own data (accessors and mutators). In a traditional EJB architecture, DTOs serve dual purposes: first, they work around the problem that entity beans are not serializable; second, they implicitly define an assembly phase where all data to be used by the view is fetched and marshalled into the DTOs before returning control to the presentation tier.

因此，对于许多人来说，dto和VOs是同一个东西(但是Fowler用VOs来表示我们看到的其他东西)。大多数时候，它们遵循javabean约定，因此也是javabean。而且都是pojo。

第一次谈论

普通类-这意味着任何类定义，通常在java中，这意味着你创建不同类型的方法属性等。 Bean - Bean什么都不是，它只是一个特定类的对象，使用这个Bean，你可以访问你的java类，就像object..

之后是最后一个POJO

POJO是一个没有任何服务的类，它只有一个默认的构造函数和私有属性，这些属性用于设置一个对应的setter和getter方法的值。 它是普通Java对象的缩写形式。

基本上,

DTO:“数据传输对象”可以在软件架构的不同层之间传输。

VO:“值对象”包含一个对象，如Integer,Money等。

POJO:普通的旧Java对象，不是一个特殊的对象。

Java Beans:要求Java类是可序列化的，有一个无参数的构造函数和每个字段的getter和setter

值对象:当需要根据对象的值来衡量对象是否相等时使用。 数据传输对象:将具有多个属性的数据一次跨层从客户端传递到服务器，避免多次调用远程服务器。 普通旧Java对象:它就像一个简单的类，有属性，公共无参数构造函数。正如我们为JPA实体声明的那样。

difference-between-value-object-pattern-and-data-transfer-pattern

javabean

JavaBean是一个遵循Sun定义的JavaBean约定的类。维基百科对javabean有一个很好的总结:

JavaBeans are reusable software components for Java that can be manipulated visually in a builder tool. Practically, they are classes written in the Java programming language conforming to a particular convention. They are used to encapsulate many objects into a single object (the bean), so that they can be passed around as a single bean object instead of as multiple individual objects. A JavaBean is a Java Object that is serializable, has a nullary constructor, and allows access to properties using getter and setter methods. In order to function as a JavaBean class, an object class must obey certain conventions about method naming, construction, and behavior. These conventions make it possible to have tools that can use, reuse, replace, and connect JavaBeans. The required conventions are: The class must have a public default constructor. This allows easy instantiation within editing and activation frameworks. The class properties must be accessible using get, set, and other methods (so-called accessor methods and mutator methods), following a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties. The class should be serializable. This allows applications and frameworks to reliably save, store, and restore the bean's state in a fashion that is independent of the VM and platform. Because these requirements are largely expressed as conventions rather than by implementing interfaces, some developers view JavaBeans as Plain Old Java Objects that follow specific naming conventions.

POJO

普通旧Java对象或POJO最初是用来指定简单的轻量级Java对象的术语，它没有实现任何javax。ejb接口，而不是重量级的ejb 2。x(特别是实体bean，无状态会话bean在我看来并不是那么糟糕)。今天，这个词被用于任何简单的物体，没有额外的东西。维基百科在定义POJO方面做得很好:

POJO is an acronym for Plain Old Java Object. The name is used to emphasize that the object in question is an ordinary Java Object, not a special object, and in particular not an Enterprise JavaBean (especially before EJB 3). The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000: "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." The term continues the pattern of older terms for technologies that do not use fancy new features, such as POTS (Plain Old Telephone Service) in telephony, and PODS (Plain Old Data Structures) that are defined in C++ but use only C language features, and POD (Plain Old Documentation) in Perl. The term has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks. A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods. An Enterprise JavaBean is not a single class but an entire component model (again, EJB 3 reduces the complexity of Enterprise JavaBeans). As designs using POJOs have become more commonly-used, systems have arisen that give POJOs some of the functionality used in frameworks and more choice about which areas of functionality are actually needed. Hibernate and Spring are examples.

值对象

值对象或VO是一个对象，例如java.lang.Integer，它保存值(因此是值对象)。对于更正式的定义，我经常参考Martin Fowler对Value Object的描述:

In Patterns of Enterprise Application Architecture I described Value Object as a small object such as a Money or date range object. Their key property is that they follow value semantics rather than reference semantics. You can usually tell them because their notion of equality isn't based on identity, instead two value objects are equal if all their fields are equal. Although all fields are equal, you don't need to compare all fields if a subset is unique - for example currency codes for currency objects are enough to test equality. A general heuristic is that value objects should be entirely immutable. If you want to change a value object you should replace the object with a new one and not be allowed to update the values of the value object itself - updatable value objects lead to aliasing problems. Early J2EE literature used the term value object to describe a different notion, what I call a Data Transfer Object. They have since changed their usage and use the term Transfer Object instead. You can find some more good material on value objects on the wiki and by Dirk Riehle.

数据传输对象

数据传输对象(DTO)是EJB引入的一种(反)模式。与其在ejb上执行许多远程调用，其思想是将数据封装在一个可以通过网络传输的值对象中:数据传输对象。维基百科对数据传输对象有一个很好的定义:

Data transfer object (DTO), formerly known as value objects or VO, is a design pattern used to transfer data between software application subsystems. DTOs are often used in conjunction with data access objects to retrieve data from a database. The difference between data transfer objects and business objects or data access objects is that a DTO does not have any behaviour except for storage and retrieval of its own data (accessors and mutators). In a traditional EJB architecture, DTOs serve dual purposes: first, they work around the problem that entity beans are not serializable; second, they implicitly define an assembly phase where all data to be used by the view is fetched and marshalled into the DTOs before returning control to the presentation tier.

因此，对于许多人来说，dto和VOs是同一个东西(但是Fowler用VOs来表示我们看到的其他东西)。大多数时候，它们遵循javabean约定，因此也是javabean。而且都是pojo。

DTO vs VO

DTO -数据传输对象只是用于在层和层之间传输数据的数据容器。

它主要包含属性。您甚至可以使用没有getter和setter的公共属性。 数据传输对象不包含任何业务逻辑。

类比:具有用户名属性的简单注册表单， 密码和电子邮件id。 当这个表单在RegistrationServlet文件中提交时，您将获得从视图层到您传递的业务层的所有属性 将属性转移到java bean，然后转移到DAO或持久层。 DTO有助于将属性从视图层传输到业务层，并最终传输到持久层。

DTO主要用于在网络上有效地传输数据，甚至可以从JVM传输到另一个JVM。

dto通常是java.io.Serializable——以便跨JVM传输数据。

VO - A值对象[1][2]表示自身是一组固定的数据，类似于Java枚举。值对象的标识基于它们的状态，而不是它们的对象标识，并且是不可变的。一个真实世界的例子就是Color。红色,颜色。蓝色,性。女等。

和贾豆

[1] POJO的java - bean性是通过符合JavaBeans约定的公共getter和setter来访问它的私有属性。如。

    private String foo;
    public String getFoo(){...}
    public void setFoo(String foo){...}; 

[２] JavaBeans必须实现Serializable并具有无参数构造函数，而在POJO中则没有这些限制。