Jaka jest różnica między JavaBean a POJO?


210

Nie jestem pewien różnicy. Używam Hibernacji, aw niektórych książkach używają JavaBean i POJO jako terminu wymiennego. Chcę wiedzieć, czy istnieje różnica, nie tylko w kontekście hibernacji, ale jako ogólne pojęcia.

Odpowiedzi:


252

JavaBean przestrzega pewnych konwencji. Nazwy getter / setter, posiadanie publicznego domyślnego konstruktora, możliwość szeregowania itp. Zobacz Konwencje JavaBeans, aby uzyskać więcej informacji.

POJO (zwykły stary obiekt Java) nie jest rygorystycznie zdefiniowany. Jest to obiekt Java, który nie wymaga implementacji określonego interfejsu lub wywodzi się z konkretnej klasy bazowej, ani nie korzysta z określonych adnotacji w celu zachowania zgodności z danym frameworkiem i może być dowolnym dowolnym (często stosunkowo prostym) Obiekt Java.


41
Zauważ, że JavaBean może być i zwykle jest POJO, a wiele POJO to tak naprawdę JavaBeans.
Joachim Sauer

8
Nie, z definicji POJO Java Bean nie jest POJO, ponieważ aby zostać uznanym za Java Bean, klasa musi przestrzegać pewnych konwencji kodowania (np. Mieć konstruktor bez argonu, mieć metody, które zaczynają się od słów „get” i / lub „set”) lub być dystrybuowane za pomocą klasy BeanInfo.
Nat

15
Ponieważ są to konwencje , myślę, że możesz skutecznie argumentować, że fasola może być POJO (np. Nie dziedziczysz po interfejsie JavaBean lub podobnym)
Brian Agnew

1
Specyfikacja JavaBeans nie definiuje komponentu JavaBean inaczej niż bardzo luźno jako „komponent oprogramowania wielokrotnego użytku” (lub niektóre takie). Nie musi mieć konstruktora bez argumentu, nie potrzebuje metod zaczynających się od „get” lub „set”, nie musi być szeregowalny, nawet nie musi być klasą.
Tom Hawtin - tackline

4
W kategoriach matematycznych możemy powiedzieć, że Jawajczycy tworzą podzbiór POJO, ponieważ szczególne ograniczenia nałożone na POJO sprawiają, że jest to Javabean.
Nishit,

106

Wszystkie JavaBeans są POJO, ale nie wszystkie POJO są JavaBeans.

JavaBean to obiekt Java, który spełnia pewne konwencje programowania:

  • klasa JavaBean musi implementować Serializable lub Externalizable;
  • klasa JavaBean musi mieć publiczny konstruktor bez arg;
  • wszystkie właściwości JavaBean muszą mieć publiczne metody ustawiające i pobierające (odpowiednio);
  • wszystkie zmienne instancji JavaBean powinny być prywatne.

1
Myślałem, że POJO nie mogą wdrożyć Serializable.
naXa

10
„klasa JavaBean musi mieć konstruktor bez argumentu;” dodaj również publiczną tutaj
radistao

JavaBean jest serializowalny i dlatego JavaBean NIE jest POJO.
karlihnos

25

Według Martina Fowlera POJO to obiekt, który zawiera logikę biznesową, podczas gdy komponent bean (z wyjątkiem definicji już podanej w innych odpowiedziach) jest niewiele więcej niż pojemnikiem do przechowywania danych, a operacje dostępne na obiekcie po prostu ustawiają i pobierają dane.

Termin ten został wymyślony, gdy Rebecca Parsons, Josh MacKenzie i ja przygotowywaliśmy się do rozmowy na konferencji we wrześniu 2000 r. Podczas rozmowy wskazywaliśmy na wiele korzyści z kodowania logiki biznesowej w zwykłe obiekty Java zamiast używania Entity Beans. Zastanawialiśmy się, dlaczego ludzie są tak przeciwni używaniu zwykłych obiektów w swoich systemach i doszliśmy do wniosku, że dzieje się tak, ponieważ proste obiekty nie mają wymyślnej nazwy. Więc daliśmy im jeden i jest bardzo ładnie przyjęty.

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


7

POJO: Jeśli klasa może być wykonana z bazowym JDK, bez żadnej obsługi zewnętrznych bibliotek stron trzecich, wówczas nazywana jest POJO

JavaBean: Jeśli klasa zawiera tylko atrybuty z akcesoriami (ustawiającymi i pobierającymi), są one nazywane javabeans. Ziarna Java na ogół nie będą zawierać żadnej logiki biznesowej, a raczej te, które służą do przechowywania niektórych danych.

Wszyscy Jawajczycy są POJO, ale wszyscy POJO nie są Jawajczycy


7

Pojo - Zwykły stary obiekt Java

klasa pojo to zwykła klasa bez żadnych specjalizacji, klasa całkowicie luźno powiązana z technologią / frameworkiem. klasa nie implementuje z technologii / frameworka i nie rozciąga się od technologii / frameworku api, ta klasa nazywa się klasą pojo.

klasa pojo może implementować interfejsy i rozszerzać klasy, ale superklasa lub interfejs nie powinny być technologią / ramą.

Przykłady:

1.

class ABC{
----
}

Klasa ABC nie implementuje ani nie rozszerza technologii / frameworka, dlatego jest to klasa pojo.

2)

class ABC extends HttpServlet{
---
}

Klasa ABC wychodząca z apletu technologii serwletowej, dlatego nie jest to klasa pojo.

3)

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

Klasa ABC implementuje z rmi api, dlatego nie jest to klasa pojo.

4

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

interfejs ten jest częścią języka Java, a nie częścią technologii / frameworku. więc jest to klasa pojo.

5

class ABC extends Thread{
--
}

tutaj wątek jest także klasą języka Java, więc jest to również klasa pojo.

6.

class ABC extends Test{
--
}

jeśli klasa Test rozszerza lub implementuje z technologii / frameworka, to ABC również nie jest klasą pojo, ponieważ dziedziczy właściwości klasy Test. jeśli klasa testowa nie jest klasą pojo, to klasa ABC również nie jest klasą pojo.

7

teraz ten punkt jest wyjątkowym przypadkiem

@Entity
class ABC{
--
}

@Entityjest adnotacją podaną przez hibernację api lub jpa api, ale nadal możemy nazwać tę klasę klasą pojo. klasa z adnotacjami podanymi z technologii / frameworka w tym wyjątkowym przypadku nazywana jest klasą pojo.



1

POJOSz pewnymi konwencjami (getter / setter, publiczny konstruktor bez argumentu, zmienne prywatne) i działają (np. są używane do odczytu danych według formularza) JAVABEANS.


1

Podsumowując: podobieństwa i różnice to:

   java beans:                          Pojo:
-must extends serializable              -no need to extends or implement.
 or externalizable.                     
-must have public class .               - must have public class
-must have private instance variables.      -can have any access specifier variables.
-must have public setter and getter method. - may or may not have setter or getter method.
-must have no-arg constructor.           - can have constructor with agruments.

Wszystkie ziarna JAVA są POJO, ale nie wszystkie POJO są ziarnami JAVA.


0

Widziałeś formalne definicje powyżej, bo wszystkie są warte.

Ale nie przejmuj się definicjami. Spójrzmy bardziej na sens rzeczy tutaj.

JavaBeans są używane w aplikacjach Java dla przedsiębiorstw, w których użytkownicy często uzyskują dostęp do danych i / lub kodu aplikacji zdalnie, tj. Z serwera (przez sieć lub sieć prywatną) za pośrednictwem sieci. W związku z tym dane muszą być przesyłane strumieniowo w formacie szeregowym do lub z komputerów użytkowników - stąd potrzeba obiektów Java EE do implementacji interfejsu Serializable. Taki charakter JavaBean nie różni się niczym od obiektów aplikacji Java SE, których dane są wczytywane lub zapisywane w systemie plików. Niezawodne używanie klas Java w sieci z szeregu kombinacji komputer-użytkownik systemu operacyjnego wymaga także przyjęcia konwencji w zakresie ich obsługi. Stąd wymóg implementowania tych klas jako publicznych, z prywatnymi atrybutami, konstruktorem bez argumentów oraz znormalizowanymi modułami pobierającymi i ustawiającymi.

Aplikacje Java EE będą również korzystać z klas innych niż te, które zostały zaimplementowane jako JavaBeans. Mogą być one wykorzystywane do przetwarzania danych wejściowych lub organizowania danych wyjściowych, ale nie będą wykorzystywane do obiektów przesyłanych przez sieć. Dlatego powyższe rozważania nie muszą być stosowane do paska, który jest poprawny jako obiekty Java. Te ostatnie klasy są nazywane POJO - Plain Old Java Objects.

Podsumowując, można zobaczyć Java Beans jako obiekty Java przystosowane do użycia w sieci.

Od 1995 roku w świecie oprogramowania jest bardzo dużo szumu - i niemało humbug.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.