Я понял, я думаю, что "Bean" - это класс Java со свойствами и геттерами/сеттерами. Насколько я понимаю, это эквивалент структуры Си. Это правда?
Кроме того, есть ли реальная синтаксическая разница между бином и обычным классом? Есть какое-то специальное определение или интерфейс?
В основном, почему есть термин для этого?
И что означает интерфейс Serializable?
JavaBean - это просто стандарт
Serializable.Это. Это просто соглашение. От этого зависит множество библиотек.
Что касается Serializable, из документации API:
Сериализуемость класса обеспечивается классом, реализующим интерфейс java.io.Serializable. Классы, которые не реализуют этот интерфейс, не будут сериализованы или десериализованы. Все подтипы сериализуемого класса сами по себе сериализуемы. Интерфейс сериализации не имеет методов или полей и служит только для определения семантики сериализации.
Другими словами, сериализуемые объекты могут быть записаны в потоки и, следовательно, файлы, объектные базы данных, что угодно.
Кроме того, нет никакой синтаксической разницы между JavaBean и другим классом - класс является JavaBean, если он следует стандартам.
Для этого есть термин, потому что стандарт позволяет библиотекам программным образом делать вещи с экземплярами классов, которые вы определяете предопределенным способом. Например, если библиотека хочет передать поток любого объекта, который вы передаете в нее, она знает, что может, потому что ваш объект сериализуем (предполагая, что библиотека требует, чтобы ваши объекты были соответствующими JavaBeans).
Есть термин, чтобы сделать его звучащим особенным. Реальность далеко не такая загадочная.
В основном, "Боб":
java.io.Serializable и делает это правильно), чтоgetFoo() является геттером для свойства "Foo"), иОбновить:
Что касается Serializable: это не что иное, как "маркерный интерфейс" (интерфейс, который не объявляет никаких функций), который сообщает Java, что реализующий класс согласен (и подразумевает, что он способен) "сериализовать" - процесс, который преобразует экземпляр в поток байтов. Эти байты могут храниться в файлах, отправляться по сетевому соединению и т.д. И иметь достаточно информации, чтобы позволить JVM (по крайней мере, тот, который знает о типе объекта) восстановить объект позже - возможно, в другом экземпляре приложение, или даже на другой машине!
Конечно, чтобы сделать это, класс должен соблюдать определенные ограничения. Главным среди них является то, что все поля экземпляров должны быть либо примитивными типами (int, bool и т.д.), Экземплярами некоторого класса, который также сериализуем, или помечены как transient чтобы Java не пыталась включить их. (Это, конечно, означает, что transient поля не выживут при прохождении через поток. Класс, имеющий transient поля, должен быть готов к их повторной инициализации в случае необходимости.)
Класс, который не может соблюдать эти ограничения, не должен реализовывать Serializable (и, IIRC, компилятор Java даже не допустит этого).
JavaBeans - это классы Java, которые придерживаются чрезвычайно простого соглашения о кодировании. Все, что вам нужно сделать, это
java.io.Serializable - чтобы сохранить состояние объектаСвойства JavaBeans
JavaBean - это объект Java, который удовлетворяет определенным соглашениям о программном обеспечении:
Класс JavaBean должен реализовать либо Serializable, либо
Externalizable
Класс JavaBean должен иметь конструктор no-arg
Все свойства JavaBean должны иметь общедоступные методы настройки и генерации
Все переменные экземпляра 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. Java EE JavaBeans Activation Framework использует Java Beans для интеграции поддержки типов данных MIME в Java EE. API управления Java EE использует JavaBeans в качестве основы для инструментария управления ресурсами в среде Java EE.
О сериализации:
В сериализации объектов объект может быть представлен как последовательность байтов, которая включает данные объекта, а также информацию о типе объекта и типах данных, хранящихся в объекте.
После того, как сериализованный объект был записан в файл, он может быть прочитан из файла и десериализован, то есть информация о типе и байты, которые представляют объект и его данные, могут быть использованы для воссоздания объекта в памяти.
Вы найдете Сериализацию полезной при развертывании вашего проекта на нескольких серверах, поскольку beans будет сохраняться и переноситься через них.
Согласно Википедии:
Класс должен иметь открытый конструктор по умолчанию (без аргументов). Это позволяет легко создавать экземпляры в рамках редактирования и активации.
Свойства класса должны быть доступны с помощью get, set, (может использоваться для логических свойств вместо get) и других методов (так называемых методов доступа и методов мутаторов) в соответствии со стандартным соглашением об именах. Это позволяет легко автоматизировать проверку и обновление состояния bean в рамках фреймворка, многие из которых включают настраиваемые редакторы для различных типов свойств. У сеттеров может быть один или несколько аргументов.
Класс должен быть сериализуемым. [Это позволяет приложениям и фреймворкам надежно сохранять, сохранять и восстанавливать состояние bean способом, не зависящим от VM и платформы.]
Для получения дополнительной информации следуйте этой ссылке .
Java Beans является стандартом, и его основные требования синтаксиса были четко объяснены другими ответами.
Однако, IMO, это больше, чем простой стандарт синтаксиса. Реальный смысл или предполагаемое использование Java Beans вместе с различными инструментальными средствами поддержки вокруг стандарта облегчает повторное использование кода и разработку программного обеспечения на основе компонентов, то есть позволяет разработчикам создавать приложения путем сборки существующих компонентов (классов) и без необходимости напишите любой код (или нужно только написать небольшой код клея). К сожалению, эта технология недооценивается и недоиспользуется отраслью, что можно объяснить из ответов в этой теме.
Если вы читаете учебник Oracle на Java Beans, вы можете получить лучшее понимание в этом.
Что касается второй части вашего вопроса, сериализация - это механизм персистентности, используемый для хранения объектов в виде последовательности подписанных байтов. Проще говоря, он сохраняет состояние объекта, поэтому вы можете получить его позже, путем де-сериализации.
Java Bean - это Java-класс [концептуальный], который должен следовать следующим соглашениям:
Это многоразовый программный компонент. Он может инкапсулировать много объектов в один объект, чтобы один и тот же объект можно было получить из нескольких мест и это шаг к простому обслуживанию кода.
Они сериализуемы, имеют конструктор с нулевым аргументом и разрешают доступ к свойствам с использованием методов getter и setter. Название "Bean" было предоставлено для охвата этого стандарта, целью которого является создание повторно используемых программных компонентов для Java. according to wiki
Объекты, составляющие основу вашего приложения и управляемые контейнером IoC Spring, называются beans. A bean - это объект, который создается, монтируется и управляется иным образом контейнером IoC Spring. В противном случае bean является просто одним из многих объектов вашего приложения.
according to spring io.
Java Beans - это обычные классы Java, которые следуют определенным соглашениям - вам не нужны специальные инструменты для их создания.
При создании классов Java Bean должно выполняться два основных соглашения:
Java Bean по сути является классом, который классифицирует класс как bean:
Приятно отметить, что поле 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;
}}
Просто небольшой фон/обновление концепции бина. Многие другие ответы на самом деле имеют, что, но не так много, почему из них.
Они были изобретены на ранних этапах Java как часть создания графических интерфейсов. Они следовали шаблонам, которые легко разбирались инструментами, позволяя им создать панель свойств, чтобы вы могли редактировать атрибуты Бина. В общем, свойства Bean представляют элемент управления на экране (Think x, y, width, height, text,..)
Вы также можете думать об этом как о строго типизированной структуре данных.
Со временем они стали полезными для многих инструментов, которые использовали один и тот же тип доступа (например, Hibernate для сохранения структур данных в базе данных).
По мере развития инструментов они стали больше ориентироваться на аннотации и не разбирать имена сеттеров и геттеров. Теперь большинству систем не требуются bean-компоненты, они могут использовать любой простой старый объект Java с аннотированными свойствами, чтобы сообщить им, как ими манипулировать.
Теперь я вижу бины как аннотированные шары свойств - они действительно полезны только для аннотаций, которые они несут.
Сами бобы не являются здоровым образцом. Они разрушают инкапсуляцию по своей природе, так как они подвергают все свои свойства внешним манипуляциям, и по мере их использования существует тенденция (ни в коем случае не требование) создавать код для манипулирования бином извне вместо создания кода внутри бина (нарушает "дон" не просите объект для его значений, попросите объект сделать что-то для вас "). Использование аннотированных pojos с минимальным числом получателей и без установщиков - это намного больше, чем ОО, восстанавливающее инкапсуляцию и возможность неизменности.
Кстати, когда все это происходило, кто-то расширил концепцию до чего-то под названием Enterprise Java Beans. Это... разные. и они достаточно сложны, чтобы многие люди чувствовали, что они не поняли всей концепции Бина, и перестали использовать этот термин. Я думаю, именно поэтому вы обычно слышите bean-компоненты, называемые POJO (поскольку каждый java-объект является POJO, это технически нормально, но когда вы слышите, как кто-то говорит POJO, они чаще всего думают о чем-то, что следует биновому шаблону)
Чтобы понять 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 на удивление легко. Вам не нужен специальный инструмент и вам не нужно реализовывать какие-либо интерфейсы. Написание бинов - это просто вопрос соблюдения определенных соглашений кодирования. Все, что вам нужно сделать, это сделать ваш класс похожим на bean - инструменты, использующие bean, смогут распознавать и использовать ваш bean. " Тривиально, даже следующий класс является 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-спецификация требует, чтобы у управляемых bean-компонентов были открытые конструкторы с нулевым аргументом. Далее говорится: "Начиная с версии 2.3 данной спецификации, использование средства управляемых компонентов, указанного в этом разделе, настоятельно не рекомендуется. Лучшим и более согласованным решением для решения той же проблемы является использование контекстов и инъекций зависимостей (CDI), как указано в JSR-365. "Другими словами, должны использоваться управляемые bean-компоненты CDI, которые обеспечивают безопасное внедрение зависимостей на конструкторы, родственные к бинам Spring. Спецификация CDI принимает спецификацию Managed Beans, которая применяется ко всем контейнерам платформы JEE, а не только к веб-уровню. Таким образом, веб-контейнер должен реализовывать спецификацию CDI.
Вот выдержка из спецификации управляемого бина "Управляемые компоненты - это управляемые контейнером объекты с минимальными требованиями, иначе известный под аббревиатурой "POJO" (простые старые объекты Java)… их можно рассматривать как расширенную платформу Java EE модели компонентов JavaBeans, найденной на платформе Java SE…. Читатель не будет упускать из виду, что в управляемых компонентах есть предшественник в одноименном средстве, найденном в технологии JavaServer Faces (JSF)… Управляемые компоненты, как определено в этой спецификации, представляют собой обобщение элементов, найденных в JSF; в частности, управляемые бины могут использоваться где угодно в приложении Java EE, а не только в веб-модулях. Например, в базовой модели компонентов управляемые компоненты должны предоставлять конструктор без аргументов, но спецификация, основанная на управляемых компонентах, такая как CDI (JSR-299), может ослабить это требование и позволить управляемым компонентам предоставлять конструкторам больше сложные подписи, если они следуют некоторым четко определенным правилам... Управляемый компонент не должен быть: конечным классом, абстрактным классом, нестатическим внутренним классом. Управляемый компонент не может быть сериализуемым в отличие от обычного компонента JavaBean. ' Таким образом, спецификация для управляемых бинов, иначе называемая POJO или бобами POJO, допускает расширение, как в CDI.
Спецификация CDI переопределяет управляемые компоненты как: При работе в Java EE класс Java верхнего уровня является управляемым компонентом, если он соответствует требованиям:
• Это не внутренний класс. • Это неабстрактный класс или аннотированный @Decorator. • Он не реализует javax.enterprise.inject.spi.Extension. • Это не аннотировано @Vetoed или в аннотированном пакете @Vetoed. • У него есть соответствующий конструктор: у класса есть конструктор без параметров, либо класс объявляет конструктор с аннотацией @Inject.
Все Java-классы, которые удовлетворяют этим условиям, являются управляемыми bean-компонентами, и поэтому нет специального объявления требуется определить управляемый компонент. Или
если он определен как управляемый компонент любым другая спецификация Java EE и, если
• Он не аннотируется аннотацией, определяющей компонент EJB, и не объявляется как класс EJB-компонента. в ejb-jar.xml.
В отличие от bean-компонентов Spring, он не поддерживает конструкторы с простыми типами, что могло бы быть возможно, если бы он поддерживал конфигурацию с XML файлами конфигурации, такими как Spring, или любыми аннотациями.
EJB работают в контейнере EJB. Его спецификация гласит: "Компонент сессионного компонента является управляемым компонентом." У класса должен быть открытый конструктор, который не принимает аргументов ", - говорится в нем как для сессионного компонента, так и для объекта, управляемого сообщениями. Далее говорит: "Класс сессионного компонента не требуется для реализации интерфейса SessionBean или интерфейса Serializable". По той же причине, что и бины JSF, то, что внедрение зависимостей EJB3 является в основном внедрением ресурсов, компоненты JSF не поддерживают конструкторы с аргументами, то есть посредством внедрения зависимостей. Однако, если контейнер EJB реализует CDI, "необязательно: класс может иметь дополнительный конструктор, аннотированный аннотацией Inject, 'он говорит и для сессионного компонента, и для компонента, управляемого сообщениями, потому что' EJB, упакованный в архив компонента CDI и не аннотированный с помощью javax.enterprise.inject.Vetoed аннотации, считается включенным CDI боб ".