Czym dokładnie jest JavaBean?

Zrozumiałem, jak sądzę, że „Fasola” to klasa Java z właściwościami i modułami pobierającymi / ustawiającymi. O ile rozumiem, jest to odpowiednik struktury C. Czy to prawda?

Ponadto, czy istnieje prawdziwa różnica składniowa między fasolą a klasą regularną? Czy jest jakaś specjalna definicja lub interfejs?

Zasadniczo, dlaczego istnieje na to termin?

Co również oznacza Serializableinterfejs?

JavaBean to tylko standard

1. Wszystkie właściwości prywatne (użyj pobierających / ustawiających )
2. Publiczny konstruktor bez argumentów
3. Narzędzia Serializable.

Otóż ​​to. To tylko konwencja. Wiele bibliotek zależy od tego.

W odniesieniu do Serializable, z dokumentacji API :

Serializacja klasy jest włączona przez klasę implementującą interfejs java.io.Serializable. Klasy, które nie implementują tego interfejsu, nie będą miały żadnego zserializowanego stanu ani zserializowanego. Wszystkie podtypy klasy możliwej do serializacji są same w sobie serializowane. Interfejs serializacji nie ma żadnych metod ani pól i służy jedynie do identyfikacji semantyki możliwości serializacji.

Innymi słowy, serializowane obiekty mogą być zapisywane w strumieniach, a zatem pliki, bazy danych obiektów, wszystko naprawdę.

Ponadto nie ma różnicy składniowej między JavaBean a inną klasą - klasa jest JavaBean, jeśli spełnia standardy.

Jest na to określenie, ponieważ standard pozwala bibliotekom programowo robić rzeczy z instancjami klas, które zdefiniujesz w określony sposób. Na przykład, jeśli biblioteka chce przesyłać strumieniowo dowolny obiekt, który do niej przekazujesz, wie, że może, ponieważ Twój obiekt jest szeregowalny (zakładając, że biblioteka wymaga, aby Twoje obiekty były poprawne JavaBeans).

Jest taki termin, aby zabrzmiało to wyjątkowo. Rzeczywistość nie jest tak tajemnicza.

Zasadniczo „Fasola”:

• jest obiektem możliwym do serializacji (to znaczy implementuje java.io.Serializablei robi to poprawnie), że
• ma „właściwości”, których metody getFoo()pobierające i ustawiające są po prostu metodami o określonych nazwach (np. jest funkcją pobierającą właściwość „Foo”) i
• ma publiczny konstruktor 0-arg (więc można go dowolnie tworzyć i konfigurować, ustawiając jego właściwości).

Aktualizacja:

Co do Serializable: To nic innego jak „interfejs znaczników” (interfejs, który nie deklaruje żadnych funkcji), który mówi Javie, że klasa implementująca wyraża zgodę (i implikuje, że jest w stanie) na „serializację” - proces, który konwertuje instancja w strumień bajtów. Te bajty mogą być przechowywane w plikach, przesyłane przez połączenie sieciowe itp. I mają wystarczającą ilość informacji, aby JVM (przynajmniej taki, który wie o typie obiektu) mógł później zrekonstruować obiekt - być może w innej instancji aplikacji, a nawet na całej innej maszynie!

Oczywiście, aby to zrobić, klasa musi przestrzegać pewnych ograniczeń. Najważniejsze z nich polega na tym, że wszystkie pola instancji muszą być albo pierwotnymi typami (int, bool itp.), Instancjami jakiejś klasy, która jest również transientmożliwa do serializacji, lub oznaczonymi w taki sposób, aby Java nie próbowała ich uwzględnić. (To oczywiście oznacza, że transientpola nie przetrwają podróży przez strumień. Klasa, która ma transientpola, powinna być przygotowana do ich ponownej inicjalizacji w razie potrzeby.)

Klasa, która nie może przestrzegać tych ograniczeń, nie powinna implementować Serializable(a IIRC, kompilator Java nawet na to nie pozwala .)

JavaBeans to klasy Java, które są zgodne z niezwykle prostą konwencją kodowania. Wszystko co musisz zrobić, to zrobić

1. implementuj java.io.Serializableinterfejs - aby zapisać stan obiektu
2. użyj publicznego pustego konstruktora argumentów - aby utworzyć instancję obiektu
3. zapewnić publiczne metody pobierające / ustawiające - aby uzyskać i ustawić wartości zmiennych prywatnych (właściwości).

Właściwości JavaBeans

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

1. JavaBean klasa musi implementować albo Serializablealbo Externalizable

2. Klasa JavaBean musi mieć konstruktor bez argumentu

3. Wszystkie właściwości JavaBean muszą mieć publiczne metody ustawiające i pobierające

4. Wszystkie zmienne instancji JavaBean powinny być prywatne

Przykład JavaBeans

@Entity
public class Employee implements Serializable{

   @Id
   private int id;
   private String name;   
   private int salary;  

   public Employee() {}

   public Employee(String name, int salary) {
      this.name = name;
      this.salary = salary;
   }
   public int getId() {
      return id;
   }
   public void setId( int id ) {
      this.id = id;
   }
   public String getName() {
      return name;
   }
   public void setName( String name ) {
      this.name = name;
   }
   public int getSalary() {
      return salary;
   }
   public void setSalary( int salary ) {
      this.salary = salary;
   }
}

Wyjaśnienie na przykładzie.

1. import java.io.Serializable

Jeśli chodzi o serializację, zobacz dokumentację .

2. pola prywatne

Pola powinny być prywatne, aby klasy zewnętrzne nie mogły łatwo modyfikować tych pól. Zamiast bezpośredniego dostępu do tych pól, zwykle stosuje się metody getter / setter.

3. Konstruktor

Konstruktor publiczny bez żadnych argumentów.

4. getter / setter

Metody pobierające i ustawiające do uzyskiwania dostępu i modyfikowania pól prywatnych.

/** 1. import java.io.Serializable */
public class User implements java.io.Serializable {
    /** 2. private fields */
    private int id;
    private String name;

    /** 3. Constructor */
    public User() {
    }
    public User(int id, String name) {
        this.id = id;
        this.name = name;
    }

    /** 4. getter/setter */
    // getter
    public int getId() {
        return id;
    }
    public String getName() {
        return name;
    }
    // setter
    public void setId(int id) {
        this.id = id;
    }
    public void setName(String name) {
        this.name = name;
    }
}

Java Beans wykorzystuje mniej kodu i więcej pracy ... Java Beans jest używana w całej Java EE jako uniwersalna umowa na wykrywanie i dostęp do środowiska wykonawczego. Na przykład JavaServer Pages (JSP) używa komponentów Java Beans jako obiektów przesyłania danych między stronami lub między serwletami i stronami JSP. JavaBeans Activation Framework Java EE wykorzystuje Java Beans do integracji obsługi typów danych MIME z Java EE. Interfejs API Java EE Management wykorzystuje JavaBeans jako podstawę instrumentacji zasobów zarządzanych w środowisku Java EE.

Informacje o serializacji:

W serializacji obiektu obiekt może być reprezentowany jako sekwencja bajtów, która zawiera dane obiektu, a także informacje o typie obiektu i typach danych przechowywanych w obiekcie.

Po zapisaniu serializowanego obiektu w pliku można go odczytać z pliku i dokonać deserializacji, to znaczy informacje o typie i bajty reprezentujące obiekt oraz jego dane można wykorzystać do odtworzenia obiektu w pamięci.

Przekonasz się, że Serializacja jest przydatna podczas wdrażania projektu na wielu serwerach, ponieważ komponenty bean zostaną utrwalone i przeniesione na nie.

Java Beans jest standardem, a jego podstawowe wymagania dotyczące składni zostały wyjaśnione innymi odpowiedziami.

IMO to jednak coś więcej niż zwykły standard składni. Rzeczywiste znaczenie lub zamierzone użycie Java Beans polega na tym, że wraz z różnymi narzędziami wspierającymi standard, ułatwia ponowne wykorzystanie kodu i inżynierię oprogramowania opartą na komponentach, tj. Umożliwia programistom tworzenie aplikacji poprzez składanie istniejących komponentów (klas) i bez konieczności pisania jakichkolwiek kod (lub wystarczy napisać trochę kodu kleju). Niestety ta technologia jest zdecydowanie niedoceniana i niedostatecznie wykorzystywana przez przemysł, co można stwierdzić na podstawie odpowiedzi w tym wątku.

Jeśli przeczytasz samouczek Oracle na temat Java Beans , możesz lepiej to zrozumieć.

Zgodnie z Wikipedią:

1. Klasa musi mieć domyślny konstruktor publiczny (bez argumentów). Umożliwia to łatwe tworzenie instancji w ramach do edycji i aktywacji.

2. Właściwości klasy muszą być dostępne przy użyciu get, set, is (można użyć dla właściwości boolowskich zamiast get) i innych metod (tak zwanych metod akcesorów i metod mutatora) zgodnie ze standardową konwencją nazewnictwa. Umożliwia to łatwą automatyczną kontrolę i aktualizację stanu komponentu w ramach, z których wiele zawiera niestandardowe edytory dla różnych typów właściwości. Seterzy mogą mieć jeden lub więcej argumentów.

3. Klasa powinna być serializowalna. [Pozwala to aplikacjom i platformom na niezawodne zapisywanie, przechowywanie i przywracanie stanu komponentu bean w sposób niezależny od maszyny wirtualnej i platformy.]

Aby uzyskać więcej informacji, skorzystaj z tego linku.

Jeśli chodzi o drugą część pytania, serializacja jest mechanizmem trwałości służącym do przechowywania obiektów jako sekwencji podpisanych bajtów. Mówiąc mniej formalnie, przechowuje stan obiektu, dzięki czemu można go później odzyskać, usuwając serializację.

Java Bean to klasa Java (konceptualna), która powinna być zgodna z następującymi konwencjami:

1. Powinien mieć konstruktor bez argumentu.
2. Powinien być możliwy do serializacji.
3. Powinien zapewniać metody ustawiania i pobierania wartości właściwości, znane jako metody pobierające i ustawiające.

Jest to komponent oprogramowania wielokrotnego użytku. Może obudować wiele obiektów w jeden obiekt, dzięki czemu można uzyskać dostęp do tego samego obiektu z wielu miejsc i jest krokiem w kierunku łatwego utrzymania kodu.

Można je serializować, mają konstruktor zerowy i umożliwiają dostęp do właściwości za pomocą metod pobierających i ustawiających. Nazwa „Fasola” została nadana, aby objąć ten standard, którego celem jest tworzenie komponentów oprogramowania wielokrotnego użytku dla Java. according to wiki

Obiekty tworzące szkielet aplikacji i zarządzane przez kontener Spring IoC są nazywane fasolami. Fasola to obiekt, który jest tworzony w instancji, składany i w inny sposób zarządzany przez kontener Spring IoC. W przeciwnym razie fasola jest po prostu jednym z wielu obiektów w aplikacji. according to wiosna io .

Tylko trochę tła / aktualizacja koncepcji ziarna. Wiele innych odpowiedzi ma właściwie to, ale nie tak bardzo dlaczego.

Zostały one wynalezione wcześnie w Javie w ramach tworzenia GUI. Postępowali zgodnie z wzorami, które były łatwe do rozłożenia przez narzędzia, pozwalając im utworzyć panel właściwości, aby można było edytować atrybuty fasoli. Zasadniczo właściwości komponentu Bean reprezentowały kontrolkę na ekranie (Pomyśl x, y, szerokość, wysokość, tekst, ...)

Możesz również myśleć o tym jako o silnie typowanej strukturze danych.

Z czasem stały się one przydatne w wielu narzędziach, które korzystały z tego samego typu dostępu (na przykład Hibernacja w celu utrwalenia struktur danych w bazie danych)

W miarę ewolucji narzędzi przesunęli się bardziej w kierunku adnotacji i odeszli od oddzielania nazwisk setera / gettera. Teraz większość systemów nie wymaga fasoli, mogą wziąć dowolny zwykły stary obiekt Java z właściwościami z adnotacjami, aby powiedzieć im, jak nimi manipulować.

Teraz widzę fasolę jako kulki właściwości z adnotacjami - są one naprawdę przydatne tylko do adnotacji, które niosą.

Same fasole nie są zdrowym wzorem. Z natury niszczą enkapsulację, ponieważ narażają wszystkie swoje właściwości na manipulację zewnętrzną, a gdy są używane, istnieje tendencja (bynajmniej nie wymaganie) do tworzenia kodu do manipulowania fasolą zewnętrznie zamiast tworzenia kodu w fasoli (narusza „don nie pytaj obiektu o jego wartości, poproś obiekt, aby coś dla ciebie zrobił ”). Używanie adnotacji z minimalnymi getterami i bez seterów to znacznie więcej OO przywracania enkapsulacji i możliwości niezmienności.

Nawiasem mówiąc, gdy wszystko to się działo, ktoś rozszerzył koncepcję na coś zwanego Enterprise Java Beans. To są ... różne. i są na tyle skomplikowane, że wiele osób uznało, że nie rozumie całej koncepcji Fasoli i przestało używać tego terminu. Myślę, że dlatego generalnie słyszysz fasolę nazywaną POJO (ponieważ każdy obiekt Java jest POJO, jest to technicznie OK, ale kiedy słyszysz, jak ktoś mówi POJO, najczęściej myśli o czymś, co odpowiada wzorowi fasoli)

Java Bean to dowolna klasa java, która spełnia następujące trzy kryteria:

1. Powinien implementować interfejs szeregowalny (interfejs Markera).
2. Konstruktor powinien być publiczny i nie może zawierać argumentów (co inni nazywają „konstruktorem bez argonu”).
3. Powinien mieć gettera i setera.

Warto zauważyć, że pole serialVersionUID jest ważne dla utrzymania stanu obiektu. Poniższy kod kwalifikuje się jako fasola:

public class DataDog implements java.io.Serializable {

private static final long serialVersionUID = -3774654564564563L;

private int id;
private String nameOfDog;

//The constructor should NOT have arguments
public DataDog () {}


/** 4. getter/setter */

// getter(s)
public int getId() {
    return id;
}
public String getNameOfDog() {
    return nameOfDog;
}
// setter(s)
public void setId(int id) {
    this.id = id;
}
public void setNameOfDog(String nameOfDog) {
    this.nameOfDog = nameOfDog;
}}

Aby zrozumieć JavaBean, musisz zwrócić uwagę na następujące kwestie: JavaBean jest konceptualny i nie może reprezentować klasy określonych rzeczy

JavaBean to narzędzie programistyczne, które można wizualizować w działaniu komponentów oprogramowania wielokrotnego użytku

JavaBean jest oparty na specyfikacji Sun JavaBeans i może być składnikiem wielokrotnego użytku. Jego największą cechą jest możliwość ponownego użycia.

Fasola to klasa Java z nazwami metod zgodnymi z wytycznymi Java Bean (zwanymi również wzorami projektowymi) dla właściwości , metod i zdarzeń. Zatem każda publiczna metoda klasy fasoli, która nie jest częścią definicji właściwości, jest metodą fasoli. W minimalnym stopniu klasa Java, nawet z właściwością jako jedynym elementem (oczywiście, towarzyszącym publicznemu pobieraniu i ustawianiu), metoda publiczna jako jedyny element członkowski lub tylko jedna metoda rejestracji publicznego nasłuchiwania zdarzeń to komponent Java. Ponadto właściwość może być albo właściwością tylko do odczytu (ma metodę gettera, ale nie ma metody ustawiającej) lub właściwością tylko do zapisu (ma tylko metodę metody ustawiającej). Fasola Java musi być klasą publiczną, aby była widoczna dla dowolnego narzędzia lub kontenera beanbox. Kontener musi mieć możliwość jego utworzenia; dlatego też musi mieć też publicznego konstruktora. Specyfikacja JavaBeansnie wymaga, aby komponent bean miał publiczny konstruktor zero-args, jawny lub domyślny, aby kontener mógł go utworzyć. Jeśli możesz podać plik (z rozszerzeniem .ser) zawierający serializowane wystąpienie, narzędzie beanbox może użyć tego pliku do utworzenia instancji prototypowego komponentu bean. W przeciwnym razie komponent bean musi mieć publiczny konstruktor zero-args, jawny lub domyślny.

Po utworzeniu instancji komponentu bean API Java Bean (java.beans. *) Może go introspekować i wywoływać na nim metody. Jeśli nie jest dostępna żadna klasa implementująca interfejs BeanInfo lub rozszerzająca implementację BeanInfo, klasa SimpleBeanInfo, introspekcja polega na użyciu odbicia (niejawnej introspekcji) w celu zbadania metod obsługiwanych przez fasolę docelową, a następnie zastosowania prostych wzorców projektowych (wytycznych), aby wywnioskować z metody te, jakie właściwości, zdarzenia i metody publiczne są obsługiwane. Jeśli dostępna jest klasa implementująca interfejs BeanInfo (dla fasoli Foo, musi mieć nazwę FooBeanInfo), interfejs API omija niejawną introspekcję i korzysta z publicznych metod (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) tej klasy, aby uzyskać Informacja. Jeśli dostępna jest klasa rozszerzająca SimpleBeanInfo, w zależności od tego, które z publicznych metod SimpleBeanInfo (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) zostaną zastąpione, użyje tych przesłoniętych metod, aby uzyskać informacje; dla metody, która nie jest przesłonięta, domyślnie zostanie zastosowana odpowiednia ukryta introspekcja. I tak należy utworzyć instancję fasoli, nawet jeśli nie zostanie na niej przeprowadzona żadna domniemana introspekcja. Zatem wymóg publicznego konstruktora zer-args. Ale oczywiście interfejs Serializowalny lub Zewnętrzny nie jest konieczny do rozpoznania. Jednak specyfikacja Java Bean mówi: „Chcielibyśmy również, aby była„ trywialna ”w przypadku zwykłego przypadku małej fasoli, która po prostu chce zachować swój stan wewnętrzny i nie chce o tym myśleć”. Tak więc wszystkie komponenty bean muszą implementować interfejs Serializable lub Externalizable. Ogólnie, Specyfikacja JavaBeans nie jest trudna i szybka w kwestii tego, co stanowi fasolę. „Pisanie komponentów JavaBeans jest zaskakująco łatwe. Nie potrzebujesz specjalnego narzędzia i nie musisz implementować żadnych interfejsów. Pisanie ziaren to po prostu kwestia przestrzegania pewnych konwencji kodowania. Wszystko, co musisz zrobić, to sprawić, by klasa wyglądała jak fasola - narzędzia wykorzystujące fasolę będą w stanie rozpoznać i wykorzystać twoją fasolę. ” Trywialnie, nawet następująca klasa to Java Bean,

public class Trivial implements java.io.Serializable {}

Powiedzmy, konstruktor komponentu bean ma pewne parametry. Załóżmy, że niektóre są prostymi typami. Kontener może nie wiedzieć, jakie wartości mu przypisać; nawet jeśli tak się stanie, wynikowa instancja może nie nadawać się do ponownego użycia. Może to mieć sens tylko wtedy, gdy użytkownik może skonfigurować (określić wartości), powiedzmy adnotacje lub pliki konfiguracyjne xml, jak w przypadku Spring Bean. Załóżmy, że niektóre parametry są klasami lub typami interfejsów. Ponownie kontener może nie wiedzieć, jakie wartości mu przypisać. Może to mieć sens tylko wtedy, gdy użytkownik może skonfigurować (określić określone obiekty), powiedzmy adnotacje lub pliki konfiguracyjne xml. Jednak nawet w Springu (za pomocą plików konfiguracyjnych xml) przypisywanie określonych obiektów (z nazwami łańcuchów) do argumentów konstruktora (atrybut lub element argumentów konstruktora) nie jest bezpieczne dla typów; jest w zasadzie podobne do wstrzykiwania zasobów. Odwoływanie się do innych ziaren Springa (zwanych kolaborantami; przez element w elemencie argumentu konstruktora) jest w zasadzie wstrzykiwaniem zależności i dlatego jest bezpieczne. Oczywiście zależność (komponent bean współpracownika) może mieć konstruktor z wprowadzonymi parametrami; te wstrzykiwane zależności mogą mieć konstruktor z parametrami i tak dalej. W tym scenariuszu ostatecznie potrzebne byłyby niektóre klasy komponentów bean (np. MyBean.class), które kontener może utworzyć, po prostu wywołując new MyBean (), zanim będzie mógł zbudować inne współpracujące komponenty bean poprzez wstrzyknięcie zależności do konstruktorów - a zatem wymóg dotyczący fasola mieć publiczny konstruktor zero-args. Załóżmy, że jeśli kontener nie obsługuje wstrzykiwania zależności i / lub nie zezwala na przypisywanie konstruktorowi wartości prostych typów za pomocą adnotacji lub plików konfiguracyjnych XML jak w Springu, konstruktory komponentów bean nie powinny mieć parametrów. Nawet aplikacja Spring Bean potrzebuje pewnych ziaren, aby mieć publiczny konstruktor zero-args (np. W scenariuszu, w którym aplikacja Spring nie ma fasoli z prostymi typami jako argumentami konstruktora).

Fasole zarządzane JSF działają w kontenerze internetowym. Można je skonfigurować za pomocą adnotacji @ManagedBean lub pliku zasobów konfiguracyjnych aplikacji managed-bean.xml. Obsługuje jednak wstrzykiwanie tylko za pomocą wstrzykiwania zasobów (nie jest to typ bezpieczny); nie nadaje się do iniekcji na konstruktorach. Specyfikacja JSFwymaga, aby zarządzane komponenty bean musiały mieć publiczne konstruktory zero-argumentowe. Ponadto napisano: „Od wersji 2.3 niniejszej specyfikacji korzystanie z funkcji zarządzanego komponentu bean, jak określono w tej sekcji, jest zdecydowanie odradzane. Lepszym i bardziej spójnie zintegrowanym rozwiązaniem dla rozwiązania tego samego problemu jest użycie wstrzykiwania kontekstu i zależności (CDI), jak określono w JSR-365. ”Innymi słowy, należy użyć fasoli zarządzanej przez CDI, która oferuje wstrzyknięcie zależności od typu bezpiecznego dla konstruktorów podobnych do fasoli szparagowej. Specyfikacja CDI przyjmuje specyfikację Managed Beans, która ma zastosowanie do wszystkich kontenerów platformy JEE, a nie tylko warstwy WWW. W związku z tym kontener WWW musi implementować specyfikację CDI.

Oto wyciąg ze specyfikacji Managed Bean „Fasola zarządzana to obiekty zarządzane przez kontener z minimalnymi wymaganiami, znane też pod akronimem„ POJO ”(Plain Old Java Objects)… można je postrzegać jako ulepszoną platformę Java EE model komponentu JavaBeans znaleziony na platformie Java SE … Czytelnik nie umknie uwadze, że Fasola Zarządzana ma prekursor w homonimicznym obiekcie znalezionym w technologii JavaServer Faces (JSF)… Fasola Zarządzana zdefiniowana w tej specyfikacji reprezentuje uogólnienie tych, które znaleziono w JSF; w szczególności Managed Beans może być używany w dowolnym miejscu aplikacji Java EE, nie tylko w modułach sieciowych. Na przykład w podstawowym modelu komponentu Managed Beans musi zapewniać konstruktor bez argumentów, ale specyfikację opartą na Managed Beans, taką jak CDI (JSR-299), może złagodzić ten wymóg i pozwolić Fasolom zarządzanym na dostarczenie konstruktorom bardziej złożonych podpisów, o ile będą przestrzegać ściśle określonych reguł ... Fasolka zarządzana nie może być: klasą ostateczną, klasą abstrakcyjną, niestatyczną klasą wewnętrzną . Managed Bean może nie być serializowany w przeciwieństwie do zwykłego komponentu JavaBean. ” Zatem specyfikacja dla zarządzanej fasoli, zwanej inaczej POJO lub fasolą POJO, pozwala na rozszerzenie jak w CDI.

Specyfikacja CDI ponownie definiuje zarządzane komponenty bean jako: Podczas działania w Javie EE klasa Java najwyższego poziomu jest zarządzaną fasolą, jeśli spełnia wymagania:

• To nie jest klasa wewnętrzna. • Jest to klasa nieabstrakcyjna lub jest opatrzona adnotacją @Decorator. • Nie implementuje javax.enterprise.inject.spi.Extension. • Nie ma adnotacji @Vetoed ani w paczce z adnotacją @Vetoed. • Ma odpowiedni konstruktor: albo klasa ma konstruktor bez parametrów, albo klasa deklaruje konstruktor z adnotacją @Inject.

Wszystkie klasy Java, które spełniają te warunki, są zarządzanymi komponentami bean, dlatego nie jest wymagana specjalna deklaracja w celu zdefiniowania fasoli zarządzanej. Lub

jeśli jest zdefiniowany jako fasola zarządzana według dowolnej innej specyfikacji Java EE i jeśli

• Nie jest opatrzony adnotacją adnotacją definiującą komponent EJB ani zadeklarowany jako klasa komponentu EJB w pliku ejb-jar.xml.

W przeciwieństwie do fasoli Spring nie obsługuje konstruktorów z typami prostymi, co może być możliwe, jeśli obsługuje konfigurację z plikami konfiguracyjnymi xml, takimi jak Spring lub adnotacjami.

EJB działają w kontenerze EJB. Jego specyfikacjamówi: „Komponent komponentu bean sesji jest komponentem Managed Bean”. „Klasa musi mieć konstruktora publicznego, który nie przyjmuje żadnych argumentów”, mówi zarówno dla komponentu bean sesji, jak i komponentu bean sterowanego komunikatami. Ponadto mówi: „Klasa bean sesji jest nie jest wymagane do wdrożenia interfejsu SessionBean ani interfejsu szeregowego. ” Z tego samego powodu, dla którego komponenty EJB3 są wstrzykiwane w zależności od EJB3, są w zasadzie wstrzykiwaniem zasobów, komponenty JSF nie obsługują konstruktorów z argumentami, to znaczy poprzez wstrzykiwanie zależności. Jednak jeśli kontener EJB implementuje CDI, „Opcjonalnie: klasa może mieć dodatkowy konstruktor opatrzony adnotacją Inject, „mówi zarówno dla komponentu bean sesyjnego, jak i komponentu opartego na komunikatach, ponieważ:„ EJB spakowany w archiwum komponentu bean CDI i nie opatrzony adnotacją javax.enterprise.inject.Vetoed, jest uważany za obsługujący CDI fasola."

W praktyce Fasola to po prostu przedmioty przydatne w użyciu. Serializacja ich oznacza łatwość ich utrwalenia (przechowywanie w formie, którą można łatwo odzyskać).

Typowe zastosowania fasoli w prawdziwym świecie:

• proste przedmioty wielokrotnego użytku POJO (Plain Old Java Objects)
• obiekty wizualne
• Wiosna używa komponentów Bean do obsługi obiektów (na przykład obiekt użytkownika, który musi zostać zserializowany w sesji)
• EJB (Enterprise Java Beans), bardziej złożone obiekty, takie jak JSF Beans (JSF to stara dość przestarzała technologia) lub JSP Beans

W rzeczywistości Beans jest tylko konwencją / standardem, którego można oczekiwać od obiektu Java, że ​​będzie się zachowywał (serializacja) i da pewne możliwości jego zmiany (ustawienia właściwości) w określony sposób.

Jak z nich korzystać, to tylko twój wynalazek, ale najczęstsze przypadki, o których wspomniałem powyżej.