2009-09-08 13 views

Respuesta

204

Un JavaBean sigue ciertas convenciones. Nombramiento de Getter/setter, con un constructor predeterminado público, serializable, etc. Consulte JavaBeans Conventions para obtener más detalles.

POJO (plain-old-Java-object) no está rigurosamente definido. Es un objeto Java que no necesita implementar una interfaz en particular o derivar de una clase base particular, o hacer uso de anotaciones particulares para ser compatible con un marco dado, y puede ser arbitrario (a menudo relativamente simple) Objeto Java

+32

Tenga en cuenta que un JavaBean puede ser y, por lo general, es un POJO y muchos POJO son en realidad JavaBeans. –

+8

No, por la definición de POJO, un Java Bean es * no * un POJO porque para ser considerado un Java Bean, una clase debe seguir ciertas convenciones de codificación (p.tener un constructor no arg, tener métodos que comiencen con las palabras "get" y/o "set") o ser distribuido con una clase BeanInfo. – Nat

+14

Como estas son * convenciones *, creo que puede argumentar con éxito que un bean puede ser un POJO (por ejemplo, no está heredando de una interfaz JavaBean o similar) –

70

Todos los JavaBeans son POJO pero no todos los POJO son JavaBeans.

Un JavaBean es un objeto Java que satisface ciertas convenciones de programación:

  • la clase JavaBean debe implementar ya sea Serializable o Externalizable;
  • la clase JavaBean debe tener un constructor público no-arg;
  • todas las propiedades de JavaBean deben tener métodos públicos setter y getter (según corresponda);
  • todas las variables de instancia de JavaBean deben ser privadas.
+1

Pensé que los POJO no pueden implementar 'Serializable'. – naXa

+6

"la clase JavaBean debe tener un constructor no-arg;" también agregue ** público ** aquí – radistao

+0

Un JavaBean es serializable y es por eso que un JavaBean NO es un POJO. – karlihnos

15

De acuerdo con Martin Fowler un POJO es un objeto que encapsula la Lógica empresarial mientras que un Bean (excepto la definición ya indicada en otras respuestas) es poco más que un contenedor para almacenar datos y las operaciones disponibles en el objeto establecer y obtener datos.

El término fue acuñado mientras Rebecca Parsons, Josh MacKenzie y yo se preparando una ponencia en una conferencia en septiembre de 2000. En la charla que señalaban los muchos beneficios de la lógica de negocio de codificación en normal Java objetos en lugar de usar Entity Beans. Nos preguntamos por qué personas estaban tan en contra de usar objetos regulares en sus sistemas y concluyeron que era porque los objetos simples carecían de un nombre elegante. Así que les dimos uno, y se capta muy bien.

http://www.martinfowler.com/bliki/POJO.html

0

POJOS con ciertas convenciones (captador/definidor, constructor público sin argumentos, variables privadas) y están en la acción (ej. Se utiliza para leer los datos en el formulario) son JAVABEANS.

3

POJO: Si la clase se puede ejecutar con JDK subyacente, sin otras bibliotecas externas de terceros apoyen a continuación, su llamado POJO

JavaBean: Si la clase sólo contiene atributos con descriptores de acceso (setters y getters) Se llaman JavaBeans .Java beans generalmente no contendrán ninguna lógica de negocios en lugar de los que se utilizan para mantener algunos datos en él.

Todos Javabeans son POJOs pero todos POJO no son Javabeans

0

Pojo - Plain Old Java objeto

clase POJO es una clase ordinaria sin ningún tipo de especialidades, clase totalmente imprecisa de la tecnología/framework.the la clase no implementa desde tecnología/framework y no se extiende desde tecnología/framework api esa clase se llama clase pojo.

pojo class puede implementar interfaces y extender clases pero la superclase o interfaz no debe ser una tecnología/framework.

Ejemplos:

1.

class ABC{ 
---- 
} 

clase ABC no aplican o se extienden desde la tecnología/marco es por eso que esta es la clase POJO.

2.

class ABC extends HttpServlet{ 
--- 
} 

clase ABC que se extiende desde servlet API tecnología que es por qué esto no es una clase POJO.

3.

class ABC implements java.rmi.Remote{ 
---- 
} 

clase ABC implementa desde api RMI es por eso que esto no es una clase POJO.

4.

class ABC implements java.io.Serializable{ 
--- 
} 

esta interfaz es parte del lenguaje Java no es una parte de la tecnología/framework.so esta es la clase POJO.

5.

class ABC extends Thread{ 
-- 
} 

aquí hilo es también la clase de lenguaje Java por lo que esta es también una clase POJO.

6.

class ABC extends Test{ 
-- 
} 

si la clase de prueba se extiende o implementos de tecnologías/marco entonces ABC también no es una clase POJO porque hereda las propiedades de clase de prueba. si la clase de prueba no es una clase pojo, entonces la clase ABC tampoco es una clase pojo.

7.

ahora este punto es un caso excepcional

@Entity 
class ABC{ 
-- 
} 

@Entity es una anotación dada por Hibernate o JPA api pero todavía podemos llamar a esta clase como clase POJO. La clase con anotaciones dadas de la tecnología/framework se llama clase pojo por este caso excepcional.

Cuestiones relacionadas