Не могли бы вы также рассказать мне, в каких контекстах они используются? Или для чего они предназначены?
Переведено автоматически
Ответ 1
JavaBeans
JavaBean - это класс, который следует соглашениям JavaBeans, как определено Sun. В Википедии есть довольно хорошее краткое описание того, что такое JavaBeans:
JavaBeans - это повторно используемые программные компоненты для Java, которыми можно визуально манипулировать в инструменте builder. Практически это классы, написанные на языке программирования Java, соответствующие определенному соглашению. Они используются для инкапсуляции множества объектов в один объект (bean), так что их можно передавать как единый bean-объект, а не как несколько отдельных объектов. JavaBean - это Java-объект, который сериализуем, имеет нулевой конструктор и разрешает доступ к свойствам с использованием методов getter и setter.
Чтобы функционировать как класс JavaBean, класс объектов должен подчиняться определенным соглашениям об именовании методов, их конструкции и поведении. Эти соглашения позволяют создавать инструменты, которые могут использовать, повторно использовать, заменять и подключать JavaBeans.
Обязательными соглашениями являются:
Класс должен иметь общедоступный конструктор по умолчанию. Это позволяет легко создавать экземпляры в рамках фреймворков редактирования и активации.
Свойства класса должны быть доступны с помощью get, set и других методов (так называемых методов доступа и методов мутатора) в соответствии со стандартным соглашением об именовании. Это позволяет легко автоматизировать проверку и обновление состояния компонента в рамках фреймворков, многие из которых включают пользовательские редакторы для различных типов свойств.
Класс должен быть сериализуемым. Это позволяет приложениям и фреймворкам надежно сохранять и восстанавливать состояние компонента независимо от виртуальной машины и платформы.
Поскольку эти требования в основном выражены в виде соглашений, а не посредством реализации интерфейсов, некоторые разработчики рассматривают JavaBeans как простые старые объекты Java, которые следуют определенным соглашениям об именовании.
POJO
Обычный старый Java-объект или POJO - это термин, изначально введенный для обозначения простого облегченного Java-объекта, не реализующего никакого javax.ejb интерфейса, в отличие от тяжеловесного EJB 2.x (особенно Entity Beans, сессионные компоненты без состояния не так уж плохи, IMO). Сегодня этот термин используется для обозначения любого простого объекта без дополнительных элементов. Опять же, Википедия хорошо справляется с определением POJO:
POJO - это аббревиатура от простого старого Java Object. Название используется, чтобы подчеркнуть, что рассматриваемый объект является обычным объектом Java, а не специальным объектом и, в частности, не корпоративным JavaBean (особенно до EJB 3). Термин был введен Мартином Фаулером, Ребеккой Парсонс и Джошем Маккензи в сентябре 2000 года:
"Мы задавались вопросом, почему люди так против использования обычных объектов в своих системах, и пришли к выводу, что это потому, что простым объектам не хватает причудливого названия. Поэтому мы дали им одно, и оно очень хорошо прижилось ".
Этот термин продолжает набор старых терминов для технологий, которые не используют модные новые функции, такие как POTS (обычная старая телефонная служба) в телефонии и PODS (простые старые структуры данных), которые определены в C ++, но используют только функции языка C, и POD (обычная старая документация) в Perl.
Этот термин, скорее всего, получил широкое распространение из-за потребности в общем и легкодоступном термине, который контрастировал бы со сложными объектными фреймворками. JavaBean - это POJO, который сериализуем, имеет конструктор без аргументов и разрешает доступ к свойствам с использованием методов getter и setter. Enterprise JavaBean - это не отдельный класс, а целая компонентная модель (опять же, EJB 3 снижает сложность Enterprise JavaBeans).
По мере того, как проекты, использующие POJOs, стали использоваться все чаще, возникли системы, которые предоставляют POJOs некоторую функциональность, используемую во фреймворках, и больший выбор того, какие области функциональности действительно необходимы. Примеры - Hibernate и Spring.
Объект значения
Объект Value или VO - это такой объект, как java.lang.Integer который содержит значения (следовательно, объекты value). Для более формального определения я часто ссылаюсь на описание Мартином Фаулером объекта Value:
В Patterns of Enterprise Application Architecture я описал объект Value как небольшой объект, такой как Money или объект диапазона дат. Их ключевое свойство заключается в том, что они следуют семантике value, а не ссылочной семантике.
Обычно вы можете сказать им, потому что их понятие равенства не основано на идентичности, вместо этого два объекта значений равны, если все их поля равны. Хотя все поля равны, вам не нужно сравнивать все поля, если подмножество уникально - например, кодов валют для объектов currency достаточно для проверки равенства.
Общая эвристика заключается в том, что объекты значений должны быть полностью неизменяемыми. Если вы хотите изменить объект value , вам следует заменить объект новым и запретить обновлять значения самого объекта value - обновляемые объекты value приводят к проблемам с псевдонимами.
В ранней литературе по J2EE термин объект значения использовался для описания другого понятия, того, что я называю объектом передачи данных. С тех пор они изменили свое использование и вместо этого используют термин Transfer Object.
Вы можете найти еще несколько хороших материалов об объектах value на wiki и у Дирка Риле.
Объект передачи данных
Объект передачи данных или DTO - это (анти) шаблон, представленный в EJB. Вместо выполнения множества удаленных вызовов в EJB, идея заключалась в том, чтобы инкапсулировать данные в объект значения, который можно было бы передавать по сети: объект передачи данных. В Википедии есть достойное определение объекта передачи данных:
Объект передачи данных (DTO), ранее известный как объекты значений или VO, представляет собой шаблон проектирования, используемый для передачи данных между подсистемами программных приложений. DTO часто используются в сочетании с объектами доступа к данным для извлечения данных из базы данных.
Разница между объектами передачи данных и бизнес-объектами или объектами доступа к данным заключается в том, что DTO не имеет никакого поведения, за исключением хранения и извлечения своих собственных данных (средств доступа и мутаторов).
В традиционной архитектуре EJB DTO служат двояким целям: во-первых, они решают проблему, связанную с тем, что компоненты объектов не сериализуемы; во-вторых, они неявно определяют этап сборки, на котором все данные, которые будут использоваться представлением, извлекаются и маршалируются в DTO, прежде чем вернуть управление уровню представления.
Итак, для многих людей DTO и VOS - это одно и то же (но Фаулер использует VOs для обозначения чего-то другого, как мы видели). Большую часть времени они следуют соглашениям JavaBeans и, следовательно, тоже являются JavaBeans. И все они POJO.
Ответ 2
DTO против VO
DTO - объекты передачи данных - это просто контейнеры данных, которые используются для транспортировки данных между уровнями.
В основном он содержит атрибуты. Вы даже можете использовать общедоступные атрибуты без геттеров и установщиков.
Объекты передачи данных не содержат никакой бизнес-логики.
Аналогия: Простая регистрационная форма с атрибутами username, password и email id.
Когда эта форма будет отправлена в файле RegistrationServlet, вы получите все атрибуты из уровня представления на бизнес-уровень, где вы передадите атрибуты java beans, а затем DAO или уровню сохранения.
DTO помогает переносить атрибуты с уровня представления на бизнес-уровень и, наконец, на уровень сохранения.
DTO в основном использовался для эффективной передачи данных по сети, это может быть даже из JVM в другую JVM.
DTO часто используются java.io.Serializable - для передачи данных через JVM.
VO - Объект Value [1][2] представляет собой фиксированный набор данных и похож на Java enum. Идентификатор объекта Value основан на их состоянии, а не на идентификаторе объекта, и является неизменяемым. Примером из реального мира может быть Color .КРАСНЫЙ, Color.СИНИЙ, SEX.ЖЕНСКИЙ и т.д.
POJO против JavaBeans
[1] Java-функциональность POJO заключается в том, что доступ ко всем его закрытым атрибутам осуществляется через общедоступные методы получения и установки, которые соответствуют соглашениям JavaBeans. например
private String foo; public String getFoo(){...} publicvoidsetFoo(String foo){...};
[2] JavaBeans должен реализовывать Serializable и иметь конструктор без аргументов, тогда как в POJO этих ограничений нет.
Ответ 3
В принципе,
DTO: "Объекты передачи данных " могут перемещаться между отдельными уровнями в архитектуре программного обеспечения.
VO: "Объекты значений " содержат такие объекты, как целое число, деньги и т.д.
POJO: обычный старый Java-объект, который не является специальным объектом.
Java Beans: требует, чтобы Java Class быть сериализуемым, иметь no-arg конструктор и средство получения и установки для каждого поля
Ответ 4
Java Beans - это не то же самое, что EJBS.
Спецификация JavaBeans в Java 1.0 была попыткой Sun разрешить манипулирование объектами Java в IDE, которая выглядела как VB. Для объектов, которые квалифицируются как "Java Beans", были установлены правила:
Конструктор по умолчанию
Средства получения и установки для частных элементов данных, которые следуют правильному соглашению об именовании
Сериализуемый
Возможно, другие, о которых я забываю.
EJB появились позже. Они сочетают распределенные компоненты и транзакционную модель, работающие в контейнере, который управляет потоками, объединением в пулы, жизненным циклом и предоставляет сервисы. Они далеки от Java Beans.
DTO появились в контексте Java, потому что люди узнали, что спецификация EJB 1.0 была слишком "болтливой" с базой данных. Вместо того, чтобы повторять цикл для каждого элемента данных, люди массово упаковывали их в Java Beans и распространяли по всему миру.