Что такое JavaBean?

Я понял, я думаю, что «Bean» - это класс Java со свойствами и геттерами / сеттерами. Насколько я понимаю, это эквивалент структуры Си. Это правда?

Кроме того, существует ли реальная синтаксическая разница между бином и обычным классом? Есть какое-то специальное определение или интерфейс?

В основном, почему есть термин для этого?

И что означает Serializableинтерфейс?

JavaBean - это просто стандарт

1. Все свойства частные (используйте геттеры / сеттеры )
2. Публичный конструктор без аргументов
3. Реализует Serializable.

Вот и все. Это просто соглашение. Хотя от этого зависит множество библиотек.

Что касается Serializable, из документации API :

Сериализуемость класса обеспечивается классом, реализующим интерфейс java.io.Serializable. Классы, которые не реализуют этот интерфейс, не будут сериализованы или десериализованы. Все подтипы сериализуемого класса сами по себе сериализуемы. Интерфейс сериализации не имеет методов или полей и служит только для определения семантики сериализации.

Другими словами, сериализуемые объекты могут быть записаны в потоки и, следовательно, файлы, объектные базы данных, что угодно.

Кроме того, нет никакой синтаксической разницы между JavaBean и другим классом - класс является JavaBean, если он следует стандартам.

Для этого есть термин, потому что стандарт позволяет библиотекам программным образом делать вещи с экземплярами классов, которые вы определяете предопределенным способом. Например, если библиотека хочет передать поток любого объекта, который вы передаете в нее, она знает, что может, потому что ваш объект сериализуем (если библиотека требует, чтобы ваши объекты были соответствующими JavaBeans).

Есть термин, чтобы сделать его звучащим особенным. Реальность далеко не таинственна.

В основном, «Боб»:

• является сериализуемым объектом (то есть, он реализует java.io.Serializableи делает это правильно), что
• имеет «свойства», чьи методы получения и установки являются просто методами с определенными именами (как, скажем, getFoo()метод получения свойства «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 Pages (JSP) использует Java Beans в качестве объектов передачи данных между страницами или между сервлетами и JSP. JavaBEans Activation Framework использует Java Bean для интеграции поддержки типов данных MIME в Java EE. API управления Java EE использует JavaBeans в качестве основы для инструментария ресурсов, которыми нужно управлять в среде Java EE.

О Сериализации:

При сериализации объекта объект может быть представлен в виде последовательности байтов, которая включает в себя данные объекта, а также информацию о типе объекта и типах данных, хранящихся в объекте.

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

Сериализация будет полезна при развертывании вашего проекта на нескольких серверах, поскольку компоненты будут сохраняться и передаваться между ними.

Java Beans является стандартом, и его основные синтаксические требования были четко объяснены другими ответами.

Тем не менее, IMO, это больше, чем простой синтаксис стандарта. Реальное значение или предполагаемое использование Java Beans вместе с различными инструментальными средствами поддержки, соответствующими стандарту, облегчают повторное использование кода и разработку программного обеспечения на основе компонентов, то есть позволяют разработчикам создавать приложения путем сборки существующих компонентов (классов) и без необходимости писать какие-либо код (или нужно только написать немного кода клея). К сожалению, эта технология недооценена и недостаточно используется в отрасли, что можно узнать из ответов в этой теме.

Если вы прочтете руководство Oracle по Java Beans , вы сможете лучше понять это.

Согласно Википедии:

1. Класс должен иметь открытый конструктор по умолчанию (без аргументов). Это позволяет легко создавать экземпляры в рамках редактирования и активации.

2. Свойства класса должны быть доступны с использованием get, set, is (может использоваться для логических свойств вместо get) и других методов (так называемых методов доступа и методов-мутаторов) в соответствии со стандартным соглашением об именах. Это позволяет легко автоматизировать проверку и обновление состояния компонента в рамках, многие из которых включают настраиваемые редакторы для различных типов свойств. Сеттеры могут иметь один или несколько аргументов.

3. Класс должен быть сериализуемым. [Это позволяет приложениям и инфраструктурам надежно сохранять, хранить и восстанавливать состояние bean-компонента независимо от виртуальной машины и платформы.]

Для получения дополнительной информации перейдите по этой ссылке.

Что касается второй части вашего вопроса, сериализация - это механизм сохранения, используемый для хранения объектов в виде последовательности подписанных байтов. Говоря менее формально, он сохраняет состояние объекта, чтобы вы могли получить его позже, десериализацией.

Java Bean - это Java-класс [концептуальный], который должен следовать следующим соглашениям:

1. Он должен иметь конструктор без аргументов.
2. Это должно быть Serializable.
3. Он должен предоставлять методы для установки и получения значений свойств, известные как методы получения и установки.

Это программный компонент многократного использования. Он может инкапсулировать множество объектов в один объект, так что один и тот же объект может быть доступен из нескольких мест, и это шаг к простому обслуживанию кода.

Они сериализуемы, имеют конструктор с нулевым аргументом и предоставляют доступ к свойствам с использованием методов getter и setter. Название «Bean» было дано для охвата этого стандарта, целью которого является создание программных компонентов многократного использования для Java. according to вики

Объекты, которые образуют основу вашего приложения и управляются контейнером Spring IoC, называются bean-компонентами. Бин - это объект, который создается, собирается и иным образом управляется контейнером Spring IoC. В противном случае бин - это просто один из множества объектов в вашем приложении. according to Весна Io .

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

Они были изобретены на ранних этапах Java как часть создания графических интерфейсов. Они следовали шаблонам, которые легко разбирались инструментами, позволяя им создать панель свойств, чтобы вы могли редактировать атрибуты Бина. В общем, свойства Bean представляют элемент управления на экране (Think x, y, width, height, text, ..)

Вы также можете думать об этом как о строго типизированной структуре данных.

Со временем они стали полезными для многих инструментов, которые использовали один и тот же тип доступа (например, Hibernate для сохранения структур данных в базе данных).

По мере развития инструментов они стали больше ориентироваться на аннотации и не разбирать имена сеттеров и геттеров. Теперь большинству систем не требуются bean-компоненты, они могут использовать любой простой старый объект Java с аннотированными свойствами, чтобы сообщить им, как ими манипулировать.

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

Сами бобы не являются здоровым образцом. Они разрушают инкапсуляцию по своей природе, поскольку они подвергают все свои свойства внешним манипуляциям, и по мере их использования существует тенденция (ни в коем случае не требование) создавать код для манипулирования бином извне, вместо создания кода внутри бина (нарушает «дон» не спрашивайте объект о его значениях, попросите объект сделать что-то для вас "). Использование аннотированных pojos с минимальным числом получателей и без установщиков - это намного больше, чем ОО, восстанавливающее инкапсуляцию и возможность неизменности.

Кстати, когда все это происходило, кто-то расширил концепцию до чего-то под названием Enterprise Java Beans. Это ... разные. и они достаточно сложны, чтобы многие люди чувствовали, что они не поняли всей концепции Бина, и перестали использовать этот термин. Я думаю, именно поэтому вы обычно слышите bean-компоненты, называемые POJO (поскольку каждый java-объект является POJO, это технически нормально, но когда вы слышите, как кто-то говорит POJO, они чаще всего думают о чем-то, что следует биновому шаблону)

Java Bean - это любой Java-класс, который удовлетворяет следующим трем критериям:

1. Он должен реализовывать сериализуемый интерфейс (интерфейс Marker).
2. Конструктор должен быть открытым и не иметь аргументов (то, что другие люди называют «конструктором без аргументов»).
3. Он должен иметь геттер и сеттеры.

Приятно отметить, что поле serialVersionUID важно для поддержания состояния объекта. Ниже код квалифицируется как bean-компонент:

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 (также называемые шаблоны проектирования) для свойств , методов и событий, Таким образом, любой открытый метод класса компонента, который не является частью определения свойства, является методом компонента. Как минимум, Java-класс даже с единственным свойством в качестве свойства (разумеется, требуются сопровождающий общедоступный метод получения и установки), открытый метод в качестве единственного члена или только один метод регистрации прослушивателя общедоступных событий - это Java-бин. Кроме того, это может быть свойство только для чтения (имеет метод получения, но не метод установки) или свойство только для записи (имеет только метод установки). Java-бин должен быть публичным классом, чтобы быть видимым для любого инструмента или контейнера beanbox. Контейнер должен быть в состоянии создать его экземпляр; таким образом, он также должен иметь открытый конструктор. JavaBeansне требует, чтобы бин имел открытый конструктор с нулевыми аргументами, явный или заданный по умолчанию, для контейнера, чтобы создать его экземпляр. Если бы вы могли предоставить файл (с расширением .ser), содержащий сериализованный экземпляр, инструмент beanbox мог бы использовать этот файл для создания экземпляра прототипа bean. В противном случае компонент должен иметь открытый конструктор с нулевым аргументом, либо явный, либо заданный по умолчанию.

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

public class Trivial implements java.io.Serializable {}

Скажем, у бобового конструктора есть некоторые параметры. Предположим, что некоторые простые типы. Контейнер может не знать, какие значения им присвоить; даже если это так, результирующий экземпляр может не использоваться повторно. Это может иметь смысл, только если пользователь может настроить (указать значения), например, аннотации или файлы конфигурации xml, как в bean-компонентах Spring. И предположим, что некоторые параметры являются типами классов или интерфейсов. Опять же, контейнер может не знать, какие значения ему присвоить. Это может иметь смысл, только если пользователь может настроить (указать конкретные объекты), скажем, аннотации или файлы конфигурации xml. Однако даже в Spring (через файлы конфигурации xml) назначение определенных объектов (с именами строк) аргументам конструктора (атрибуту или элементу аргументов конструктора) не является безопасным с точки зрения типов, это в основном похоже на внедрение ресурсов. Создание ссылок на другие bean-компоненты Spring (называемые коллабораторами; через элемент в элементе аргумента конструктора) - это, по сути, внедрение зависимости и, следовательно, безопасность типов. Очевидно, что у зависимости (bean сотрудника) может быть конструктор с внедренными параметрами; эти внедренные зависимости могут иметь конструктор с параметрами и так далее. В этом сценарии, в конечном счете, вам потребуются некоторые классы bean-компонентов (например, MyBean.class), которые контейнер может создать, просто вызвав новый MyBean (), прежде чем он сможет создать другие взаимодействующие bean-компоненты посредством внедрения зависимостей в конструкторы - таким образом, требование для бины должны иметь открытый конструктор с нулевыми аргументами. Предположим, если контейнер не поддерживает внедрение зависимостей и / или не позволяет присваивать конструктору значения простого типа через некоторые аннотации или XML-файлы конфигурации, как в Spring, конструкторы бинов не должны иметь параметров. Даже приложению Spring bean-компонентов потребовалось бы, чтобы некоторые bean-компоненты имели общедоступный конструктор с нулевыми аргументами (например, в сценарии, где у вашего Spring-приложения нет bean-компонента с простыми типами в качестве аргументов конструктора).

Управляемые компоненты JSF запускаются в веб-контейнере. Их можно настроить либо с помощью аннотации @ManagedBean, либо с помощью файла ресурсов конфигурации приложения managed-bean.xml. Тем не менее, он поддерживает инъекцию только через инъекцию ресурсов (не безопасную); не подходит для инъекций на конструкторах. JSFтребует, чтобы управляемые компоненты имели открытые конструкторы с нулевым аргументом. Далее говорится: «Начиная с версии 2.3 данной спецификации, использование средства управляемых компонентов, указанного в этом разделе, настоятельно не рекомендуется. Лучшим и более согласованным решением для решения той же проблемы является использование контекстов и инъекций зависимостей (CDI), как указано в JSR-365. «Другими словами, должны использоваться управляемые bean-компоненты CDI, которые обеспечивают безопасное внедрение зависимостей на конструкторы, родственные к бинам Spring. Спецификация CDI принимает спецификацию Managed Beans, которая применяется ко всем контейнерам платформы JEE, а не только к веб-уровню. Таким образом, веб-контейнер должен реализовывать спецификацию CDI.

Вот выдержка из спецификации Managed Bean «Управляемые компоненты - это объекты, управляемые контейнером, с минимальными требованиями, которые также известны под аббревиатурой« POJO »(простые старые объекты Java)… их можно рассматривать как расширенную платформу Java EE модели компонентов JavaBeans, найденной на платформе Java SE. .... Читатель не будет упускать из виду, что в управляемых компонентах есть предшественник в одноименном средстве, найденном в технологии JavaServer Faces (JSF)… Управляемые компоненты, как определено в этой спецификации, представляют собой обобщение элементов, найденных в JSF; в частности, управляемые компоненты могут использоваться в любом месте приложения Java EE, а не только в веб-модулях. Например, в базовой модели компонентов управляемые компоненты должны предоставлять конструктор без аргументов, но спецификацию, основанную на управляемых компонентах, такую ​​как CDI (JSR-299), может ослабить это требование и позволить управляемым компонентам предоставлять конструкторам более сложные подписи, если они следуют некоторым четко определенным правилам ... Управляемый компонент не должен быть: конечным классом, абстрактным классом, нестатическим внутренним классом , Управляемый компонент не может быть сериализуемым в отличие от обычного компонента JavaBean ». Таким образом, спецификация для управляемых бинов, иначе называемая POJO или бобами POJO, допускает расширение, как в CDI.

Спецификация CDI переопределяет управляемые bean-компоненты следующим образом: При работе в Java EE класс Java верхнего уровня является управляемым bean-компонентом, если он соответствует требованиям:

• Это не внутренний класс. • Это неабстрактный класс или аннотированный @Decorator. • Он не реализует javax.enterprise.inject.spi.Extension. • Это не аннотировано @Vetoed или в аннотированном пакете @Vetoed. • У него есть соответствующий конструктор: либо у класса есть конструктор без параметров, либо класс объявляет конструктор с аннотацией @Inject.

Все классы Java, которые удовлетворяют этим условиям, являются управляемыми bean-компонентами, и поэтому для определения управляемого bean-компонента не требуется специального объявления. Или

если он определен как управляемый компонент в любой другой спецификации Java EE, и если

• Он не аннотируется аннотацией, определяющей компонент EJB, и не объявляется как класс EJB-компонента в ejb-jar.xml.

В отличие от Spring bean-компонентов, он не поддерживает конструкторы с простыми типами, что могло бы быть возможно, если бы он поддерживал конфигурацию с XML-файлами конфигурации, такими как Spring, или любыми аннотациями.

EJB работают в контейнере EJB. это спецификация«Компонент сессионного компонента - это управляемый компонент». «У класса должен быть открытый конструктор, который не принимает аргументов», - говорится как для сессионного компонента, так и для компонента, управляемого сообщениями. Далее сказано: «Класс сессионного компонента - это не требуется для реализации интерфейса SessionBean или интерфейса Serializable ». По той же причине, что и бины JSF, то, что внедрение зависимостей EJB3 является в основном внедрением ресурсов, компоненты JSF не поддерживают конструкторы с аргументами, то есть посредством внедрения зависимостей. Однако, если контейнер EJB реализует CDI, «необязательно: класс может иметь дополнительный конструктор, аннотированный аннотацией Inject, «он говорит и для сессионного компонента, и для компонента, управляемого сообщениями, потому что« EJB, упакованный в архив компонента CDI и не аннотированный с помощью javax.enterprise.inject.Vetoed аннотации, считается включенным CDI боб «.

На практике Бобы - это просто объекты, которые удобно использовать. Сериализация их означает, что можно легко сохранять их (хранить в форме, которая легко восстанавливается).

Типичные применения Бобов в реальном мире:

• простые повторно используемые объекты POJO (Простые Старые Объекты Java)
• визуальные объекты
• Spring использует Beans для обработки объектов (например, объект User, который необходимо сериализовать в сеансе)
• EJB (Enterprise Java Beans), более сложные объекты, такие как JSF Beans (JSF - старая, довольно устаревшая технология) или JSP Beans

На самом деле, Бобы - это просто соглашение / стандарт ожидающий от объекта Java чего-либо, что он будет вести себя (сериализация), и предоставляющий некоторые способы его изменения (установки для свойств) определенным образом.

Как их использовать, это всего лишь ваше изобретение, но наиболее распространенные случаи я завербовал выше.

POJO (Обычный старый Java-объект): - POJO - это обычный Java-объект, без каких-либо ограничений, кроме обязательных для языка Java.

Сериализация: - используется для сохранения состояния объекта и отправки его по сети. Он преобразует состояние объекта в поток байтов. Мы можем воссоздать объект Java из потока байтов с помощью процесса, называемого десериализацией.

Заставьте ваш класс реализовать интерфейс java.io.Serializable. И используйте метод writeObject () класса ObjectOutputStream для достижения сериализации.

Класс JavaBean: - Это специальный POJO, который имеет некоторые ограничения (или соглашения). 1. Реализовать сериализацию 2. Иметь открытый конструктор без аргументов 3. Все свойства приватны с общедоступными методами получения и установки.

Многие фреймворки, например Spring, используют объект JavaBean.