Bean java что это

Bean java что это

Класс Java Bean должен соответствовать ряду ограничений:

• иметь конструктор, который не принимает никаких параметров
• определять для всех свойств, которые используются в jsp, методы геттеры и сеттеры
• названия геттеров и сеттеров должны соответствовать условностям: перед именем переменной добавляется get (для геттера) и set (для сеттера), а название переменной включается с большой буквы. Например, если переменная называется firstName, то функции геттера и сеттера должны называться соответственно getFirstName и setFirstName. Однако для переменных типа boolean для функции геттера используется вместо get приставка is. Например, переменная enabled и геттер isEnabled.
• реализовать интерфейс Serializable или Externalizable

Рассмотрим, как использовать классы JavaBean. Допустим, у нас есть следующая структура:

В папке Java Resources/src расположен класс User со следующим кодом:

import java.io.Serializable; public class User implements Serializable < private static final long serialVersionUID = 2041275512219239990L; private String name; private int age; public User() < this.name = ""; this.age = 0; >public User(String name, int age) < this.name = name; this.age = age; >public String getName() < return name; >public void setName(String name) < this.name = name; >public int getAge() < return age; >public void setAge(int age) < this.age = age; >>

Данный класс представляет пользователя и является классом Java Bean: он реализует интерфейс Serializable, имеет конструктор без параметров, а его методы — геттеры и сеттеры, которые предоставляют доступ к переменным name и age, соответствуют условностям.

В папке WebContent определена страница user.jsp . Определим в ней следующий код:

       
Name: $ 
Age: $
   

Данная страница jsp получает извне объект user и с помощью синтаксиса EL выводит значения его свойств. Стоит обратить внимание, что здесь идет обращение к переменным name и age, хотя они являются приватными.

В папке Java Resources/src в файле HelloServlet.java определен сервлет HelloServlet:

import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; @WebServlet("/hello") public class HelloServlet extends HttpServlet < protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException < User tom = new User("Tom", 25); request.setAttribute("user", tom); getServletContext() .getRequestDispatcher("/user.jsp") .forward(request, response); >>

Сервлет создает объект User. Для передачи его на страницу user.jsp устанавливается атрибут «user» через вызов request.setAttribute(«user», tom) . Далее происходит перенаправление на страницу user.jsp. И, таким образом, страница получит данные из сервлета.

Обратная сторона Spring

Неделя Spring на Хабре, судя по всему, открыта. Хочется сказать спасибо переводчику и комментаторам статьи «Почему я ненавижу Spring», которая не смотря на сильный негативный посыл в названии вызвала ряд интересных дискуссий, а так же тем, кто отреагировал на мою прошлую статью Как писать на Spring в 2017. Во многом благодаря комментариям к прошлой статье и появилась эта.

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

В комментариях к предыдущей статье несколько человек очень справедливо указали, что пример Hello World-а на Spring все же не очень показателен. Spring, особенно с использованием Spring Boot, дает ощущение простоты и всемогущества, но непонимание основ и внутренностей фреймворка ведет к большой опасности получить стектрейсом по логу. Что ж, чтобы немного развеять ощущение полной магии происходящего, сегодня мы возьмем приложение из предыдущей статьи и разберем, как и что происходит внутри фреймворка и от каких проблем нас отгораживает Boot. Целевая аудитория все же начинающие разработчики, но с некоторым опытом и базовыми знаниями Java и Spring. Хотя, возможно, и опытным пользователям Spring будет интересно освежить знания того, что происходит под капотом.

Ключевые понятия

Бины

Начнем срывать покровы с самых базовых понятий Spring. Бин (bean) — это не что иное, как самый обычный объект. Разница лишь в том, что бинами принято называть те объекты, которые управляются Spring-ом и живут внутри его DI-контейнера. Бином является почти все в Spring — сервисы, контроллеры, репозитории, по сути все приложение состоит из набора бинов. Их можно регистрировать, получать в качестве зависимостей, проксировать, мокать и т.п.

DI контейнер

Ключевой и фундаментальный механизм Spring. Внешне очень простой, но внутри он предоставляет очень много механизмов для тонкой настройки зависимостей. По сути, любое приложение Спринг — это набор бинов, связанных вместе через DI контейнер.

Очень часто при обсуждении Spring звучит аргумент, что его можно легко заменить на любой леговесный DI контейнер (Guice, например) и получить то же самое, но легче и проще. И здесь очень важно понять — ценность Spring DI не в самом факте его наличия, а в его фундаментальности. Все библиотеки в экосистеме Spring, по сути, просто регистрируют свои бины в этом контейнере (включая и сам Spring) — и через иньекцию зависимостей разработчики приложения смогут получить нужные компоненты. Простой пример: при использовании Spring Security OAuth если сконфигурить параметры OAuth в application.properties , то Spring Security предоставит бин OAuth2RestTemplate который мы можем просто заинжектить в своем коде. И этот бин при обращении к внешнему API будет знать, куда и как пойти, чтобы получить OAuth токен, как его обновлять, в какое место нашего запроса его добавлять и т.п. Так вот ценность DI тут в том, что это просто механизм общения между нашим кодом и Spring Security. И простой заменой реализации DI на Guice не добиться, чтобы Spring Security тоже начал его использовать. А если в этом новом DI не будет интеграции со всеми библиотеками Spring-а, то и ценность его сильно падает.

Еще один очень важный момент, который многие упускают при обсуждении DI контейнера, это то, что использование инъекции зависимостей не подразумевает создания интерфейсов для каждого компонента. Это очень простая мысль, но я много раз видел, что из-за своей простоты она не всегда очевидна. Более того, создание интерфейса, если у него лишь одна реализация — считается плохой практикой. Т.е. классы вполне могут сами по себе быть объектами DI. Более того, отсутствие интерфейса даже не мешает их мокать в тестах, т.к. Mockito, например, вполне умеет мокать классы.

Контекст

Представлен интерфейсом ApplicationContext . По сути, представляет собой само приложение Spring. Так же контекст предоставляет возможности реагировать на различные события, которые происходят внутри приложения, управлять жизненным циклом бинов (создавать как синглтон или на каждый запрос, например).

Конфигурация

Итак, если приложение — это набор бинов, чтобы оно заработало нам нужно этот набор описать.

Конфигурация — это просто описание доступных бинов. Spring дает несколько вариантов, как можно описать набор бинов, которые сформируют приложение. Исторический вариант — это через набор xml файлов. В наши дни ему на смену пришли Java аннотации. Spring Boot построен на аннтациях чуть более, чем полностью и большинство современных библиотек в принципе тоже можно сконфигурить через аннотации. В третьем своем поколении, конфигурация бинов пришла к подходу функциональной регистрации (functional bean registration), которая станет одной из важных новых фич готовящегося к выходу Spring 5.

Типичный класс конфигурации может, выглядеть, например так:

@Configuration class PaymentsServiceConfiguration < @Bean public PaymentProvider paymentProvider() < return new PayPalPaymentProvider(); >@Bean public PaymentService paymentService(PaymentProvider paymentProvider) < return new PaymentService(paymentProvider); >>

Эта конфигурация определяет два бина, причем второй зависит от первого. И здесь в игру вступит Spring – когда мы просим предоставить инстанс PaymentProvider — Spring найдет его в контексте и предоставит нам.

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

Сканирование компонентов

Достаточно важный компонент Spring Framework, еще один подход к упрощению конфигурации приложения. Идея очень простая — если мы знаем, что наш класс MyCoolComponent должен регистрировать бин с именем myCoolComponent , зачем каждый раз писать @Bean MyCoolComponent myCoolComponent(dependencies. ) < return new MyCoolComponent(dependencies. ); >? Почему просто не дать Spring–у автоматом зарегистрировать и создать бин на основании нужного класса? Эту задачу и решает сканирование компонентов. Т.е. если мы объявим наш класс как

@Component class MyCoolComponent < MyCoolComponent(dependencies. ) < >>

и разрешим сканирование компонентов — то Spring сам создаст и зарегистрирует бин с именем myCoolComponent , использовав конструктор класса и заинжектив туда все зависимости.

Со сканированием компонентов надо быть осторожным, т.к. по сути оно неявно меняет контекст приложения. Например, если у нас есть интерфейс и две реализации — и на каждом указан @Component , то при попытке заинжектить зависимость на интерфейс Spring бросит исключение, что есть два бина, которые удовлетворяют запросу.

Резюме

Итак, вещи которые нужно запомнить: приложение Spring, описанное интерфейсом ApplicationContext , представляет собой набор объектов (бинов), управляемых DI контейнером. Конфигурация набора бинов осуществляется с помощью классов конфигурации (аннотация @Configuration ), которые могут быть комбинированы с помощью импортов (аннотация @Import ).

Spring Boot

Теперь переходим к следующей части. Допустим, нам надо сконфигурить подключение к MySQL базе данных. Если мы хотим использовать Spring Data JPA с Hibernate в качестве провайдера, нам потребуется сконфигурировать несколько бинов — EntityManagerFactory (основной класс JPA), DataSource для подключения непосредственно к базе через JDBC драйвер и т.п. Но с другой стороны, если мы это делаем каждый раз и, по сути, делаем одно и то же — почему бы это не автоматизировать? Скажем, если мы указали строку подключения к базе и добавили зависимость на MySQL драйвер — почему бы чему-то автоматически не создать все нужные бины для работы с MySQL? Именно это и делает Spring Boot. По сути, Spring Boot это просто набор классов конфигурации, которые создают нужные бины в контексте. Точно так же их можно создать руками, просто Boot это автоматизирует.

Автоконфигурация

Важное понятие Spring Boot это автоконфигурация. По сути, это просто набор конфигурационных классов, которые создают и регистрируют определенные бины в приложении. По большому счету, даже сам Embedded Servlet Container — это просто еще один бин, который можно сконфигурировать! Пара важных моментов, которые важно знать об автоконфигурации:

• Включается аннотацией @EnableAutoConfiguration
• Работает в последнюю очередь, после регистрации пользовательских бинов
• Принимает решения о конфигурации на основании доступных в classpath классов, свойств в application.properties и т.п.
• Можно включать и выключать разные аспекты автоконфигурации, и применять ее частично (например, только MySQL + JPA, но не веб)
• Всегда отдает приоритет пользовательским бинам. Если ваш код уже зарегистрировал бин DataSource — автоконфигурация не будет его перекрывать

Условия и порядок регистрации бинов

Логика при регистрации бинов управляется набором @ConditionalOn* аннотаций. Можно указать, чтобы бин создавался при наличии класса в classpath ( @ConditionalOnClass ), наличии существующего бина ( @ConditionalOnBean ), отсуствии бина ( @ConditionalOnMissingBean ) и т.п.

Spring Boot активно использует эти аннотации чтобы оставаться как можно более незаметным и не перекрывать пользовательские конфигурации.

Погружение в Hello World

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

Итак, наше приложение включает такой код:

@SpringBootApplication public class DemoApplication < public static void main(String[] args) < SpringApplication.run(DemoApplication.class, args); >>

Давайте разберем что здесь происходит по шагам.

Класс DemoApplication

Этот класс помечен аннотацией @SpringBootApplication , что является мета-аннотацией, т.е. по сути, является алиасом для нескольких аннотаций:

• @SpringBootConfiguration
• @EnableAutoConfiguration
• @ComponentScan .

Т.е. наличие @SpringBootApplication включает сканирование компонентов, автоконфигурацию и показывает разным компонентам Spring (например, интеграционным тестам), что это Spring Boot приложение

SpringApplication.run()

Это просто хелпер, который делает пару вещей — используя список предоставленных конфигураций (а класс DemoApplication сам по себе конфигурация, см. выше) создает ApplicationContext , конфигурирует его, выводит баннер в консоли и засекает время старта приложения и т.п. Его можно заменить на ручное создание контекста: new AnnotationConfigApplicationContext(DemoApplication.class) . Как можно понять из названия, это контекст приложения, который конфигурируется с помощью аннотаций. Однако, этот контекст не знает ничего об embedded servlet container-ах, и совершенно точно не умеет себя запускать. Его наследник, уже из Spring Boot — AnnotationConfigEmbeddedWebApplicationContext делать это вполне умеет, и если мы в методе main напишем просто

@SpringBootApplication public class DemoApplication < public static void main(String[] args) throws InterruptedException < ApplicationContext applicationContext = new AnnotationConfigEmbeddedWebApplicationContext(DemoApplication.class); >>

То получим точно такое же работающее приложение, т.к. класс AnnotationConfigEmbeddedWebApplicationContext найдет в контексте бин типа EmbeddedServletContainerFactory и через него создаст и запустит встроенный контейнер. Обратите внимание, что все это работает в рамках общего DI контейнера, то есть этот класс можно реализовать самим.

@EnableAutoConfiguration

Эта аннотация включает автоконфигурацию. И здесь, пожалуй, ключевой момент в развенчании магии Spring. Вот как объявлена эта аннотация:

. @Import(EnableAutoConfigurationImportSelector.class) public @interface EnableAutoConfiguration

Т.е. это самый обычный импорт конфигурации, про который мы говорили выше. Класс же EnableAutoConfigurationImportSelector (и его преемник в Spring Boot 1.5+ — AutoConfigurationImportSelector ) это просто конфигурация, которая добавит несколько бинов в контекст. Однако, у этого класса есть одна тонкость — он не объявляет бины сам, а использует так называемые фабрики.

Класс EnableAutoConfigurationImportSelector смотрит в файл spring.factories и загружает оттуда список значений, которые являются именами классов (авто)конфигураций, которые Spring Boot импортирует.

Кусочек файла spring.factories (он находится в папке META-INF внутри spring-boot-autoconfigure..jar ), который нам сейчас нужен это:

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\ . (100 lines) org.springframework.boot.autoconfigure.webservices.WebServicesAutoConfiguration

Т.е. аннотация @EnableAutoConfiguration просто импортирует все перечисленные конфигурации, чтобы предоставить нужные бины в контекст приложения.

По сути, ее можно заменить на ручной импорт нужных конфигураций:

@Import(< org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration.class, org.springframework.boot.autoconfigure.aop.AopAutoConfiguration.class, . >) public class DemoApplication

Однако, особенность в том, что Spring Boot пытается применить все конфигурации (а их около сотни). Я думаю, у внимательного читателя уже появилась пара вопросов, которые стоит прояснить.

• «Но это же медленно!». И да, и нет — под рукой нет точных цифр, но сам по себе процесс автоконфигурации очень быстрый (порядка сотни миллисекунд на абстрактной машине в вакууме)
• «Но это же излишне, зачем мне конфигурить Rabbit ( RabbitAutoConfiguration ) если я его не использую?». Наличие автоконфигурции не значит, что бин будет создан. Автоконфигурационные классы активно используют @ConditionalOnClass аннотации, и в большинстве случаев конфигурация ничего делать и создавать не будет (см. выше «Условия и порядок регистрации бинов»).

Краткое резюме

В основе «магии» Spring Boot нет ничего магического, он использует совершенно базовые понятия из Spring Framework. В кратком виде процесс можно описать так:

1. Аннотация @SpringBootApplication включает сканирование компонентов и авто-конфигурацию через аннотацию @EnableAutoConfiguration
2. @EnableAutoConfiguration импортирует класс EnableAutoConfigurationImportSelector
3. EnableAutoConfigurationImportSelector загружает список конфигураций из файла META-INF/spring.factories
4. Каждая конфигурация пытается сконфигурить различные аспекты приложения (web, JPA, AMQP etc), регистрируя нужные бины и используя различные условия (наличие / отсутствие бина, настройки, класса и т.п.)
5. Созданный в итоге AnnotationConfigEmbeddedWebApplicationContext ищет в том же DI контейнере фабрику для запуска embedded servlet container
6. Servlet container запускается, приложение готово к работе!

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

Диагностика

Auto-configuration report

В случае, когда что-то идет не так, Spring Boot позволяет запустить диагностику автоконфигурации и посмотреть, какие именно бины были созданы. Чтобы увидеть эту информацию, нужно запустить приложение с ключом —debug .

java -jar my-app.jar --debug

В ответ Spring выдаст детальный Auto-configuration report:

========================= AUTO-CONFIGURATION REPORT ========================= Positive matches: ----------------- DataSourceAutoConfiguration matched: - @ConditionalOnClass found required classes 'javax.sql.DataSource', 'org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseType'; @ConditionalOnMissingClass did not find unwanted class (OnClassCondition) DataSourceAutoConfiguration#dataSourceInitializer matched: - @ConditionalOnMissingBean (types: org.springframework.boot.autoconfigure.jdbc.DataSourceInitializer; SearchStrategy: all) did not find any beans (OnBeanCondition) . Negative matches: ----------------- ActiveMQAutoConfiguration: Did not match: - @ConditionalOnClass did not find required classes 'javax.jms.ConnectionFactory', 'org.apache.activemq.ActiveMQConnectionFactory' (OnClassCondition) . 

Строчка в Positive / Negative matches будет для каждой примененной автоконфигурации, более того, Boot сообщит, почему тот или иной бин был создан (т.е. укажет, какие из условий регистрации были выполнены).

Actuator

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

После добавления Actuator к проекту, Spring Boot опубликует список доступных бинов через URL http://localhost:8080/beans . Этот список так же доступен через JMX (Java Management Extensions), и последняя версия Intellij IDEA умеет показывать все бины приложения прямо из окна запуска.

Резюме

Spring все же остается большим и не самым простым фреймворком, но это цена высокоуровневых абстракций, которые он предоставляет. И хотя знать все тонкости работы фреймворка в ежедневной разработке не нужно, знать, как он работает изнутри, все же, полезно. Надеюсь, что эта статья помогла понять важность и ценность Spring именно как экосистемы и убрала немного «магичности» в происходящем, особенно при использовании Spring Boot. Мой совет — не бойтесь углубляться в недра фреймворка, читайте исходники и документацию, благо они у Spring-a почти эталонные, на мой взгляд.

Так же стоит отметить, что в готовящемся к выходу в сентябре Spring 5 появится несколько новых концепций, направленных на создание простых приложений, и понижение уровня «магии» (хотя, как мы выяснили, магии там особо и нет). Одна из концепций это Functional Bean Registration, которая позволяет регистрировать бины в контексте с помощью функций, или даже с помощью неплохого DSL на Kotlin (а Spring 5 добавит много хорошего для поддержки Kotlin). Следующая, но еще более важная вещь, это комбинация Functional Web Framework и WebFlux (reactive web framework), которая позволит создавать веб-приложения вообще без зависимости на Spring MVC и запускать их без сервлет контейнеров. Приложение вполне сможет работать без контекста приложений и DI, и описываться просто как набор функций request -> response . Об этом можно чуть больше почитать здесь (на английском).

Что такое bean в Spring

Не могу понять что такое Bean в википедии написано это как просто доменный объект, есть еще сервисы, контроллеры, DAO, что из них является бином и почему так называется, что я не так понимаю?

Отслеживать
задан 2 окт 2015 в 5:01
2,068 7 7 золотых знаков 35 35 серебряных знаков 70 70 бронзовых знаков
2 окт 2015 в 6:02

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

В Spring-е бином (bean) называют любой класс, который управляется контейнером Spring. То есть такими вещами, как создание экземпляра бина, его инициализация, внедрение зависимостей и параметров, деинициализация, генерация всевозможных оберток над бином, занимается не ваш код, а IoC-контейнер Spring-а.

Отслеживать
ответ дан 17 окт 2015 в 22:19
34.4k 15 15 золотых знаков 65 65 серебряных знаков 94 94 бронзовых знака
Получается и сервис и domain и controller являются бином?
19 окт 2015 в 2:51
Если они болтаются спринговом контейнере — они являются spring-бинами.
19 окт 2015 в 6:56

Ну по сути это класс с некоторыми ограничениями. 1)Конструктор используется без параметров. 2) Все поля private с доступом через геттер и сеттер.

Отслеживать
ответ дан 2 окт 2015 в 6:54
Евгений Платов Евгений Платов
1,353 1 1 золотой знак 8 8 серебряных знаков 7 7 бронзовых знаков
Почему я объявляю сервис бином почему не доменный объект не объявить, для чего он объявляется
2 окт 2015 в 8:55

Ни первое, ни второе, неверно. Может быть использован конструктор. Приватные поля могут инжектиться в случае использования автовайринга.

Bean java что это

Объекты JavaBean определяют простую и мощную модель компонентов для Java. Цель объектов JavaBean — предоставить отдельные и многоразовые единицы, которыми разработчики могут управлять как программно, так и визуально с помощью инструментов компоновки.

Объекты JavaBean могут быть управляющими элементами GUI, но могут быть и не представленными визуально. Управляющие элементы GUI в Java обычно являются объектами JavaBean, чтобы ими можно было управлять инструментами компоновки. В J2EE простые объекты JavaBean обычно берутся из JSP, где они обеспечивают разделение презентации на языке HTML и кода на языке Java, содержащегося в объектах JavaBean.

Объект JavaBean — это класс Java с тремя различными составляющими:

Свойства JavaBean

Свойства JavaBean доступны другим компонентам. Обычно свойство — это частное значение, которое можно получить с помощью методов set и get, но оно может быть и вычисляемым значением. Обновление свойств может вызывать различные побочные эффекты.

Методы доступа к свойствам иногда называют аксессорами. Аксессоры могут быть методами get и set и подчиняются соглашениям об именах:

void setимя_свойства(тип_свойства value); // метод set
тип_свойства getимя_свойства() // метод get

Для булевского свойства метод get может быть следующим:

boolean isимя_свойства() // метод get для булевского свойства

Пример: пользовательский объект JavaBean

Ниже приведен пример простого объекта JavaBean (Customer) с двумя простыми свойствами: name и email. Обратите внимание, что свойства определяются парами методов set/get.

public class Customer private String name;
private String email;

public String getName() return name;
>

public void setName(String aName) name = aName;
>

public String getEmail() return email;
>

public void setEmail(String aEmail) email = aEmail;
>

Такие простые объекты JavaBean часто используются в JSP, где они позволяют передавать значения из форм Web-страниц.

Индексированные свойства

Помимо простых свойств, которые могут принимать только одно значение, существуют и свойства — массивы значений.

Индексированные свойства могут возвращать значение по указанному индексу или целый массив значений.

У индексированных свойств следующие сигнатуры:

void setимя_свойства(int index, тип_свойства value); // индексированный set
тип_свойства getter(int index); // индексированный get
void setимя_свойства(тип_свойства values[]); // массив set
тип_свойства[]getимя_свойства(); // массив get

Привязанные свойства

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

Объект JavaBean с привязанным свойством предлагает методы регистрации и отмены регистрации заинтересованных объектов, называемых получателями. Разработчики могут определить свой собственный механизм уведомлений, но библиотеки Java предоставляют несколько распространенных классов поддержки в составе пакета java.beans.

Ограниченные свойства

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

События и уведомление

События — это опция объектов JavaBean, позволяющая независимо разработанным компонентам обмениваться информацией друг с другом путем рассылки уведомлений об изменении состояния. В этой модели некоторые компоненты выдают события, а другие компоненты, находящиеся в роли получателей событий, их обрабатывают.

Для поддержки этой модели связи модель компонентов JavaBean предоставляет:

• свойства, которые могут выдавать события (привязанные и ограниченные)
• методы регистрации, чтобы получатели могли регистрироваться
• события, содержащие информацию об изменении
• получатели, которые могут реагировать на доставленное событие

Следующая диаграмма классов иллюстрирует эти концепции для объекта JavaBean EventSource с простым свойством int.

Во время настройки конкретные получатели регистрируются с объектом JavaBean. В один из последующих моментов другой объект вызывает метод setProperty, который запустит процесс уведомления путем создания объекта событий. Объект JavaBean EventSource вызовет метод propertyChange во всех зарегистрированных получателях. Получатели событий получат событие, прочтут его значения и отреагируют на него.

На следующей последовательной диаграмме иллюстрируется порядок вызовов:

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

Внутренний анализ

Внутренний анализ — это механизм среды выполнения, позволяющий обнаруживать свойства, события и методы JavaBean. Внутренний анализ применяется инструментами разработки и программами, не использующими закодированные зависимости в других компонентах. Работа механизма внутреннего анализа основана на анализе существующей информации с учетом соглашений об именах методов и интерфейсов. Класс BeanInfo поддерживает дополнительные функции внутреннего анализа. Соглашения об именах JavaBean, применяемые для внутреннего анализа, иногда называют «шаблонами проектирования», но их не следует смешивать с понятием «шаблон проектирования», существующим в объектно-ориентированном проектировании.

Постоянные данные

Объект JavaBean может постоянно храниться в памяти. Это достигается посредством механизма сериализации. Сериализация может быть автоматической или пользовательской, в зависимости от того, какие интерфейсы реализует JavaBean — сериализуемые или импортируемые. В JDK 1.4 появились новые классы XMLEncoder и XMLDecoder, позволяющие хранить экземпляры JavaBean в формате XML.

Настройка

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

BeanContext

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

Среда активации объектов JavaBean™

Среда активации Java — это стандартное расширение Java, позволяющее определять тип фрагмента данных, инкапсулировать его, выяснять набор его доступных операций и создавать экземпляр компонента программного обеспечения, отвечающего требуемой операции над этим фрагментом.

Дополнительная информация

Дополнительная информация об объектах JavaBean приведена в документе JavaBeans API Specification, Version 1.01 на Web-сайте http://java.sun.com/. Выберите ссылку Docs & Training > Java 2 Platform, Standard Edition > Java 2 SDK, SE v1.3 documentation > JavaBeans > JavaBeans Specification.

Данная информация полностью или частично разработана компанией Inferdata Corporation. © Copyright IBM Corp. 1987, 2006. Все права защищены. Читать: Как вывести таблицу mysql Предыдущая запись Bdutility hackintosh как пользоваться Следующая запись Bean spring что это Похожие записи Как отвязать интеллектуальный пульт от телевизора samsung admin25.11.2023 Где находится стартер на ваз 2105 инжектор admin25.11.2023 Как построить график функции в wolfram mathematica admin25.11.2023