Що саме таке JavaBean?

Я зрозумів, я думаю, що "Bean" - це клас Java з властивостями та getters / setters. Наскільки я розумію, це еквівалент С-структури. Це правда?

Також, чи існує реальна синтаксична різниця між квасолею та звичайним класом? Чи є якесь спеціальне визначення чи інтерфейс?

В основному, чому для цього існує термін?

Також що означає Serializableінтерфейс?

JavaBean - це просто стандарт

1. Усі об'єкти приватного користування (використовуйте геттери / сетери )
2. Загальнодоступний конструктор без аргументів
3. Здійснення Serializable.

Це воно. Це просто умовність. Однак багато бібліотек залежать від цього.

Що стосується Serializable, з документації API :

Серіалізабільність класу вмикається класом, що реалізує інтерфейс java.io.Serializable. Класи, які не реалізують цей інтерфейс, не матимуть жодного їх стану, серіалізованого чи дезаріалізованого. Всі підтипи класу, що серіалізується, самі по собі є серійними. Інтерфейс серіалізації не має методів чи полів і служить лише для ідентифікації семантики серіалізації.

Іншими словами, об'єкти, що серіалізуються, можуть записуватися в потоки, а значить, у файли, в бази даних об'єктів, будь-що насправді.

Крім того, між JavaBean та іншим класом немає синтаксичної різниці - клас є JavaBean, якщо він відповідає стандартам.

Для нього є термін, оскільки стандарт дозволяє бібліотекам програматично робити речі із визначеними вами екземплярами класу заздалегідь визначеним чином. Наприклад, якщо бібліотека хоче передавати в неї будь-який об’єкт, який ви передаєте, він знає, що це може, тому що ваш об'єкт є серіалізаційним (припускаючи, що lib вимагає, щоб ваші об'єкти були належними JavaBeans).

Існує термін, щоб це звучало особливо. Реальність ніде не є такою загадковою.

В основному, "квасоля":

• є серіалізаційним об'єктом (тобто він реалізує java.io.Serializableі робить це правильно), що
• має "властивості", getters та setters - це лише методи з певними іменами (як, скажімо, getFoo()це getter для властивості "Foo"), і
• має загальнодоступний конструктор 0-arg (тому його можна створити за бажанням і налаштувати, встановивши його властивості).

Оновлення:

Щодо Serializable: Це не що інше, як "маркерний інтерфейс" (інтерфейс, який не декларує жодних функцій), який повідомляє Java, що клас реалізації погоджується на (і означає, що він здатний) "серіалізація" - процес, який конвертує екземпляр у потік байтів. Ці байти можна зберігати у файлах, надсилати через мережеве з'єднання тощо, і мати достатньо інформації, щоб дозволити JVM (принаймні, той, хто знає про тип об'єкта), щоб потім реконструювати об'єкт - можливо, в іншому екземплярі додаток або навіть на цілком іншій машині!

Звичайно, для цього клас повинен дотримуватися певних обмежень. Головне серед них - те, що всі поля екземплярів повинні бути або примітивними типами (int, bool тощо), екземпляри якогось класу, який також може бути серіалізаційним, або позначені таким transientчином, що Java не намагатиметься їх включити. (Це, звичайно, означає, що transientполя не переживуть поїздку над потоком. Клас, який має transientполя, повинен бути готовий до їх повторної ініціалізації, якщо це необхідно.)

Клас, який не може дотримуватися цих обмежень, не повинен реалізовувати Serializable(і, IIRC, компілятор Java навіть не дозволить цього зробити.)

JavaBeans - класи Java, які дотримуються надзвичайно простого кодування. Все, що вам потрібно зробити - це зробити

1. java.io.Serializableінтерфейс реалізації - для збереження стану об’єкта
2. використовувати загальнодоступний конструктор порожніх аргументів - для екземпляра об'єкта
3. надати публічні методи отримання / встановлення - для отримання та встановлення значень приватних змінних (властивостей).

Властивості JavaBeans

JavaBean - це об'єкт Java, який задовольняє певним умовам програмування:

1. Клас JavaBean повинен реалізовувати Serializableабо Externalizable

2. Клас JavaBean повинен мати конструктор без аргументів

3. Усі властивості JavaBean повинні мати загальнодоступні методи встановлення та отримання

4. Усі змінні екземплярів JavaBean повинні бути приватними

Приклад 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;
   }
}

Пояснення з прикладом.

1. імпорт java.io.Serializable

Щодо серіалізації, дивіться документацію .

2. приватні поля

Поля повинні бути приватними, щоб запобігти зовнішнім класам легко змінювати ці поля. Замість того, щоб безпосередньо звертатися до цих полів, використовуються звичайні методи геттера / сеттера.

3. Конструктор

Громадський конструктор без жодних аргументів.

4. геттер / сетер

Методи отримання та налаштування для доступу та зміни приватних полів.

/** 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 використовують для менш кодового та більш робочого підходу ... Java Beans використовуються в усьому Java EE як універсальний контракт на пошук та доступ до виконання. Наприклад, сторінки JavaServer (JSP) використовують Java Beans як об'єкти передачі даних між сторінками або між сервлетами та JSP. Програма JavaBeans Activation Framework Java EE використовує Java Beans для інтеграції підтримки типів даних MIME в Java EE. API управління EE Java використовує JavaBeans як основу для інструментації ресурсів, якими керує в середовищі Java EE.

Про серіалізацію:

При серіалізації об'єкта об'єкт може бути представлений у вигляді послідовності байтів, яка включає дані об'єкта, а також інформацію про тип об'єкта та типи даних, що зберігаються в об'єкті.

Після того, як серіалізований об'єкт записаний у файл, він може бути прочитаний з файлу та десеріалізований, тобто інформація про тип і байти, які представляють об'єкт, та його дані, можуть бути використані для відтворення об'єкта в пам'яті.

Ви знайдете серіалізацію корисною при розгортанні свого проекту на декількох серверах, оскільки боби будуть зберігатися та передаватися через них.

Java Beans - це стандарт, і його основні вимоги до синтаксису були чітко пояснені іншими відповідями.

Однак, IMO, це більше, ніж простий стандарт синтаксису. Справжній сенс або передбачуване використання Java Beans полягає в тому, щоб разом з різними підтримками інструментів навколо стандарту сприяти повторному використанню коду та інженерії програмного забезпечення на основі компонентів, тобто дозволяти розробникам створювати програми шляхом складання існуючих компонентів (класів) і без необхідності писати будь-які код (або лише написати трохи клею). На жаль, ця технологія є недостатньо оціненою та недостатньо використаною промисловістю, про що можна сказати з відповідей у ​​цій темі.

Якщо ви прочитаєте підручник Oracle на тему Java Beans , то зможете краще зрозуміти це.

Відповідно до Вікіпедії:

1. Клас повинен мати публічний конструктор за замовчуванням (без аргументів). Це дозволяє легко інстанціювати в межах редагування та активації.

2. Властивості класу повинні бути доступними за допомогою get, set, is (може використовуватися для булевих властивостей замість get) та інших методів (так званих методів accessor та мутаторних методів) згідно зі стандартною умовою іменування. Це дозволяє легко автоматизовано перевіряти та оновлювати стан бобів у рамках, багато з яких містять спеціальні редактори для різних типів властивостей. У сеттерів може бути один або кілька аргументів.

3. Клас повинен бути серіалізаційним. [Це дозволяє програмам і рамкам надійно зберігати, зберігати та відновлювати стан бобів таким чином, що не залежить від віртуального комп'ютера та платформи.]

Для отримання додаткової інформації перейдіть за цим посиланням.

Щодо другої частини вашого запитання, серіалізація - це механізм стійкості, який використовується для зберігання об'єктів як послідовності підписаних байтів. Якщо говорити менш формально, він зберігає стан об'єкта, щоб ви могли отримати його пізніше шляхом десеріалізації.

Java Bean - клас java [концептуальний], який повинен відповідати наступним умовам:

1. Він повинен мати конструктор без аргументів.
2. Він повинен бути серіалізаційним.
3. Він повинен забезпечувати методи встановлення та отримання значень властивостей, відомих як методи getter та setter.

Це програмний компонент для багаторазового використання. Він може інкапсулювати багато об'єктів в один об'єкт, щоб той самий об’єкт можна було отримати з декількох місць і є кроком до легкого обслуговування коду.

Вони серіалізуються, мають конструктор з нульовим аргументом та дозволяють отримати доступ до властивостей за допомогою методів getter та setter. Назва "Бін" була надана для охоплення цього стандарту, який спрямований на створення програмних компонентів для багаторазового використання для Java. according to вікі

Об'єкти, що складають основу вашої програми та якими керує контейнер Spring IoC, називаються бобами. Квасоля - це об'єкт, який інстанціюється, збирається та іншим чином керується контейнером Spring IoC. В іншому випадку квасоля - це просто один із багатьох об'єктів у вашій програмі. according to весна іо .

Лише невелике тло / оновлення щодо концепції бобів. Багато інших відповідей насправді мають те, що, але не так багато, чому саме їх.

Вони були винайдені на початку Java в рамках створення графічних інтерфейсів. Вони дотримувались простих шаблонів, що дозволяють інструментам роз'єднати, дозволяючи їм створити панель властивостей, щоб ви могли редагувати атрибути Bean. Загалом, властивості Bean являли собою елемент керування на екрані (Поміркуйте x, y, ширину, висоту, текст, ..)

Ви також можете вважати це сильно набраною структурою даних.

З часом вони стали корисними для безлічі інструментів, які використовували один і той же тип доступу (наприклад, Hibernate для збереження структур даних до бази даних)

По мірі того, як інструменти розвивались, вони рухалися більше до приміток та подалі від того, щоб розбирати назви сеттера та геттера. Зараз більшість систем не потребує квасолі, вони можуть брати будь-який звичайний старий об'єкт Java з анотованими властивостями, щоб розповісти, як ними маніпулювати.

Тепер я бачу квасоля як кульки з анотованими властивостями - вони справді корисні лише для анотацій, які вони несуть.

Самі боби - це не здоровий зразок. Вони руйнують інкапсуляцію за своєю природою, оскільки вони піддають всі свої властивості зовнішньому маніпулюванню, і коли вони використовуються, існує тенденція (аж ніяк не вимога) створювати код для маніпулювання бобом зовні, а не створювати код всередині квасолі (порушує "Дон 'не запитувати об'єкт щодо його значень, попросити об'єкт зробити щось для вас "). Використання анотованих піхов з мінімальними геттерами та без сетерів набагато більше OO відновлення інкапсуляції та з можливістю незмінність.

До речі, коли все це відбувалося, хтось поширив концепцію на щось, що називається Enterprise Java Beans. Це ... різні. і вони досить складні, що багато людей відчували, що не розуміють усієї концепції Біна, і перестали використовувати цей термін. Я думаю, чому ви, як правило, чуєте боби, які називаються POJO (оскільки кожен об'єкт java - POJO, це технічно нормально, але коли ви чуєте, як хтось каже, POJO, вони найчастіше думають про щось, що відповідає шаблону квасолі)

Java Bean - це будь-який клас java, який відповідає наступним трьом критеріям:

1. Він повинен реалізовувати серіалізаційний інтерфейс (інтерфейс Маркера).
2. Конструктор повинен бути публічним і не мати аргументів (Що інші називають "конструктором без аргументів").
3. У ньому повинні бути геттери та сетери.

Добре зауважити, що поле serialVersionUID важливе для підтримки стану об'єкта. Нижче код кваліфікується як квасоля:

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;
}}

Щоб зрозуміти JavaBean, потрібно помітити наступне: JavaBean - це концептуальні речі і не можуть представляти клас конкретних речей

JavaBean - це інструмент розробки, який можна візуалізувати в роботі багаторазових програмних компонентів

JavaBean заснований на специфікації Sun JavaBeans і може бути компонентами для багаторазового використання. Найбільшою його особливістю є повторне використання.

Бін - клас Java з іменами методів, які відповідають правилам Java Bean (також називаються шаблонами дизайну) для властивостей , методів та подій. Таким чином, будь-який публічний метод класу bean, який не є частиною визначення властивості, є методом bean. Як мінімум, клас Java, навіть якщо власність є єдиним членом (звичайно, супроводжують публічний геттер і сетер), публічним методом як єдиним учасником або лише одним методом реєстрації слухачів публічних подій є Java-боб. Крім того, властивість може бути або властивістю лише для читання (має метод getter, але не setter), або властивість лише для запису (має лише метод setter). Яблуко Java має бути публічним класом, щоб його можна було побачити будь-якому інструменту чи контейнеру. Контейнер повинен мати можливість його екземпляру; таким чином, він також повинен мати публічний конструктор. Специфікація JavaBeansне вимагає, щоб bean мав публічний конструктор zero-args, явний або за замовчуванням, для контейнера для його ініціювання. Якщо ви могли б надати файл (з розширенням .ser), що містить серіалізований екземпляр, інструмент beanbox міг би використовувати цей файл для створення екземпляра прототипу. В іншому випадку bean повинен мати загальнодоступний конструктор нульових аргументів - явний або за замовчуванням.

Після того, як боб буде інстанційований, API Java Bean (java.beans. *) Може самоаналізувати його та викликати на ньому методи. Якщо немає класу, що реалізує інтерфейс BeanInfo або розширює реалізацію BeanInfo, клас SimpleBeanInfo, доступний, інтроспекція передбачає використання рефлексії (неявна інтроспекція) для вивчення методів, що підтримуються цільовим бобом, а потім застосування простих шаблонів проектування (інструкцій) для виведення ті методи, які підтримуються властивостями, подіями та загальнодоступними методами. Якщо клас, що реалізує інтерфейс BeanInfo (для біна Foo, він повинен бути названий FooBeanInfo) доступний, API обходить неявну самоаналіз і використовує публічні методи (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) цього класу, щоб отримати інформація. Якщо доступний клас, що розширює SimpleBeanInfo, залежно від того, який із загальнодоступних методів SimpleBeanInfo (getPropertyDescriptor (), getMethodDescriptors (), getEventSetDescriptors ()) буде перекрито, він буде використовувати ці перекричені методи (и) для отримання інформації; для методу, який не перекрито, він буде за замовчуванням відповідної неявної самоаналізу. Бобові потрібно все-таки придумувати, навіть якщо на ньому не проводиться неявна самоаналіз. Таким чином, вимога публічного конструктора zeri-args. Але, звичайно, інтерфейс Serializable або Externalizable не потрібен для його розпізнавання. Однак специфікація Java Bean говорить: "Ми також хотіли б, щоб вона була" тривіальною "для звичайного випадку крихітного Біна, який просто хоче зберегти свій внутрішній стан і не хоче думати про це". Отже, всі боби повинні реалізовувати інтерфейс Serializable або Externalizable. Загалом, Специфікація JavaBeans не є важкою і швидкою щодо того, що являє собою боб. "Написання компонентів JavaBeans напрочуд просто. Вам не потрібен спеціальний інструмент і вам не потрібно реалізовувати будь-які інтерфейси. Написання бобів - це лише питання дотримання певних умов кодування. Все, що вам потрібно зробити, - це зробити ваш клас схожим квасоля - інструменти, які використовують боби, зможуть розпізнати та використовувати вашу квасолю ». Тривіально, навіть наступний клас - це Java Bean,

public class Trivial implements java.io.Serializable {}

Скажімо, конструктор бобів має деякі параметри. Припустимо, деякі прості типи. Контейнер може не знати, які значення призначити їм; навіть якщо це так, то отриманий екземпляр може бути повторно використаний. Це може мати сенс лише в тому випадку, якщо користувач може налаштувати (вказати значення) за допомогою анотацій rec або файлів конфігурації xml, як у весняних бобах. І припустимо, деякі параметри - це клас або інтерфейс. Знову ж, контейнер може не знати, які значення йому призначити. Це може мати сенс лише в тому випадку, якщо користувач може налаштувати (вказати конкретні об'єкти) за допомогою анотацій скажіть або файлів конфігурації xml. Однак навіть навесні (за допомогою файлів конфігурації xml) присвоєння конкретних об'єктів (з іменами рядків) аргументам конструктора (атрибут або елемент аргументів конструктора) не є безпечним для введення тексту, це в основному як введення ресурсів. Посилання на інші весняні боби (звані колабораціоністами; через елемент в аргументі конструктора) в основному є введенням залежності і, таким чином, безпечно. Очевидно, що залежність (співпраця) може мати конструктор із введеними параметрами; ці введені залежності можуть мати конструктор з параметрами тощо. У цьому сценарії, в кінцевому підсумку, вам знадобляться деякі класи квасолі (наприклад, MyBean.class), які контейнер може створити, просто зателефонувавши до нового MyBean (), перш ніж він зможе сконструювати інші співпрацюючі боби за допомогою введення залежності від конструкторів - таким чином, вимога до боби матимуть загальнодоступний конструктор з нульовою стрілкою. Припустимо, якщо контейнер не підтримує введення залежності та / або не дозволяє призначити конструктору прості типи через деякі примітки або конфігураційні файли xml, як навесні, конструктори bean не повинні мати параметрів. Навіть у програмі Spring beans потрібні деякі боби, щоб мати загальнодоступний конструктор з нульовими args (наприклад, у сценарії, коли у вашому додатку Spring немає бобів із просто простими типами аргументів конструктора).

Квасоля, керована JSF, працює у веб-контейнері. Вони можуть бути налаштовані або з анотацією @ManagedBean, або з файлом ресурсу конфігурації програми керований-bean.xml. Однак він підтримує ін'єкцію лише за допомогою ін'єкції ресурсів (не типу); не підходить для ін'єкцій на конструкторах. Специфікація JSFвимагає, щоб керована квасоля повинна мати публічні конструктори з нульовими аргументами. Далі йдеться: “Згідно з версією 2.3 цієї специфікації використання керованого обладнання для бобів, як зазначено в цьому розділі, сильно не рекомендується. Кращим і більш згуртованим рішенням для вирішення тієї ж проблеми є використання контекстів та ін'єкцій залежностей (CDI), як зазначено в JSR-365. "Іншими словами, CDI, які керують CDI, повинні бути використані, що пропонує безпечну ін'єкційну залежність від подібних конструкторів. Спеціалізація CDI приймає специфікацію керованих бобів, яка застосовується до всіх контейнерів платформи JEE, а не лише до веб-ярусу. Таким чином, веб-контейнер повинен реалізувати специфікацію CDI.

Ось витяг із специфікації керованого квасолі "Керовані боби - це об'єкти з керуванням контейнерами з мінімальними вимогами, інакше відомі під абревіатурою" POJOs "(Звичайні старі об'єкти Java) ... їх можна розглядати як розширену версію моделі компонентів JavaBeans на платформі Java SE, розширену платформою Java EE. …. Читач не пропустить, що керовані боби мають попередник у однойменному об'єкті, знайденому в технології JavaServer Faces (JSF)… Керовані боби, як визначено в цій специфікації, являють собою узагальнення тих, що знайдені в JSF; зокрема, керовані боби можна використовувати будь-де в додатку Java EE, а не лише у веб-модулях. Наприклад, у базовій компонентній моделі Managed Beans повинен забезпечувати конструктор без аргументів, а специфікацію, яка будується на керованих бобах, таких як CDI (JSR-299), може послабити цю вимогу і дозволити керованим Beans надавати конструкторам складніші підписи, якщо вони дотримуються деяких чітко визначених правил ... Керований Бін не повинен бути: кінцевий клас, абстрактний клас, нестатичний внутрішній клас . Керований бін може не бути серіалізаційним на відміну від звичайного компонента JavaBean. " Таким чином, специфікація керованих бобів, інакше відомих як POJO або POJO-боби, дозволяє розширити, як у CDI.

Специфікація CDI повторно визначає керовані боби як: Під час роботи в Java EE класом Java верхнього рівня є керований боб, якщо він відповідає вимогам:

• Це не внутрішній клас. • Це неабразований клас, або це анотація @Decorator. • Він не реалізує javax.enterprise.inject.spi.Extension. • Це не зазначається @Vetoed або в упаковці з анотацією @Vetoed. • У ній є відповідний конструктор: у класу є конструктор без параметрів, або клас оголошує конструктор в примітці @Inject.

Усі класи Java, які відповідають цим умовам, мають керовані боби, і тому для визначення керованої квасолі не потрібно особливої ​​декларації. Або

якщо він визначений як керований боб будь-якою іншою специфікацією Java EE, і якщо

• Він не позначається анотацією, що визначає компонент EJB, або оголошується як клас EJB в ejb-jar.xml.

На відміну від весняних бобів, він не підтримує конструкторів з простими типами, що може бути можливим, якщо він підтримує конфігурацію з файлами конфігурації xml, як у Spring або будь-якими анотаціями.

EJB працюють у контейнері EJB. Його специфікаціякаже: "Компонент бін сеансу - керований бін". "Клас повинен мати публічний конструктор, який не бере ніяких аргументів", він говорить як для біна сеансу, так і для керованого повідомленнями. не потрібно для реалізації інтерфейсу SessionBean або інтерфейсу Serializable. " З тієї ж причини, що і для бобів JSF, що введення залежності EJB3 - це в основному введення ресурсів, боби JSF не підтримують конструкторів з аргументами, тобто через ін'єкцію залежностей. Однак, якщо контейнер EJB реалізує CDI, "необов'язково: клас може мати додатковий конструктор, позначений анотацією "Ін'єктувати", "говорить як про біл сеансу, так і для керованого повідомленнями, тому що:" EJB, упакований в архів CDA-бобів, а не зазначається javax.enterprise.inject.Ветанована анотація, вважається включеним в CDI квасоля ».

На практиці квасоля - це просто зручні у використанні предмети. Серіалізувати їх означає, що можна легко зберігати їх (зберігати у формі, яку легко відновити).

Типове використання квасолі в реальному світі:

• прості об'єкти для багаторазового використання POJO (Прості об'єкти старої Java)
• візуальні об’єкти
• Spring використовує Beans для об’єктів для обробки (наприклад, об’єкт User, який потрібно серіалізувати в сеансі)
• EJB (Enterprise Java Beans), більш складні об'єкти, наприклад, JSF Beans (JSF - стара досить застаріла технологія) або JSP Beans

Тож насправді Beans - це лише умова / стандарт, щоб очікувати чогось від об'єкта Java, який би він поводився (серіалізація) і дав певні способи змінити його (сеттери для властивостей) певним чином.

Як їх використовувати - це лише ваш винахід, але найчастіші випадки я перерахував вище.