JavaBeans
JavaBean - это класс, который следует соглашениям JavaBeans , как определено Sun. В Википедии есть довольно хорошее резюме того, что JavaBeans :
JavaBeans - это повторно используемые программные компоненты для Java, которыми можно манипулировать визуально в инструменте компоновщика. На практике это классы, написанные на языке программирования Java, соответствующем определенному соглашению. Они используются для инкапсуляции многих объектов в один объект (бин), чтобы их можно было передавать как один объект бина, а не как несколько отдельных объектов. JavaBean - это Java-объект, который сериализуем, имеет нулевой конструктор и предоставляет доступ к свойствам с использованием методов получения и установки.
Чтобы функционировать как класс JavaBean, объектный класс должен подчиняться определенным соглашениям в отношении именования, построения и поведения методов. Эти соглашения позволяют иметь инструменты, которые могут использовать, повторно использовать, заменять и подключать JavaBeans.
Обязательные условные обозначения:
- Класс должен иметь открытый конструктор по умолчанию. Это позволяет легко создавать экземпляры в средах редактирования и активации.
- Свойства класса должны быть доступны с использованием get, set и других методов (так называемых методов доступа и методов-мутаторов) в соответствии со стандартным соглашением об именах. Это позволяет легко автоматизировать проверку и обновление состояния компонента в рамках, многие из которых включают настраиваемые редакторы для различных типов свойств.
- Класс должен быть сериализуемым. Это позволяет приложениям и инфраструктурам надежно сохранять, хранить и восстанавливать состояние компонента в зависимости от виртуальной машины и платформы.
Поскольку эти требования в значительной степени выражаются в виде соглашений, а не в реализации интерфейсов, некоторые разработчики рассматривают JavaBeans как простые старые объекты Java, которые следуют определенным соглашениям об именах.
POJO
Простой старый Java-объект или POJO - это термин, первоначально введенный для обозначения простого облегченного Java-объекта, не реализующего какой-либо интерфейс javax.ejb, в отличие от тяжелого EJB 2.x (особенно Entity Beans, не требующие сохранения Stateless Session Beans не плохое имо). Сегодня этот термин используется для обозначения любого простого объекта без лишних вещей. Опять же, Википедия хорошо справляется с определением POJO :
POJO является аббревиатурой от Plain Old Java
Объект. Название используется, чтобы подчеркнуть
что рассматриваемый объект является
обычный Java-объект, а не специальный
объект, и, в частности, не
Enterprise JavaBean (особенно до
EJB 3). Термин был придуман Мартином
Фаулер, Ребекка Парсонс и Джош
Маккензи в сентябре 2000 года:
«Мы удивлялись, почему люди так против использования обычных предметов в своих
системы и пришли к выводу, что это было
потому что простым предметам не хватало фантазии
название. Итак, мы дали им один, и это
завоевал популярность. "
Термин продолжает образец
старые термины для технологий, которые делают
не используйте необычные новые функции, такие как
POTS (Обычная старая телефонная служба) в
телефония и PODS (обычные старые данные
Структуры), которые определены в C ++
но использовать только функции языка C, и
POD (Обычная старая документация) на Perl.
Термин скорее всего получил
широкое признание из-за
нужно общее и легко
Понятный термин, который контрастирует с
сложные объектные рамки.
JavaBean - это POJO, который
сериализуемый, без аргументов
конструктор, и позволяет получить доступ к
свойства с использованием геттера и сеттера
методы. Enterprise JavaBean не является
один класс, но целый компонент
модель (опять же, EJB 3 уменьшает
сложность Enterprise JavaBeans).
Поскольку проекты с использованием POJO стали
более часто используемые системы имеют
возникшие, которые дают POJOs некоторые из
функциональность, используемая в рамках ибольше выбора о том, какие области
функциональность действительно нужна.
Hibernate и Spring являются примерами.
Объект значения
Объект-значение или VO - это такой объект, как java.lang.Integer, который содержит значения (следовательно, объекты-значения). Для более формального определения я часто обращаюсь к описанию Мартина Фаулера Value Object :
В Шаблонах Архитектуры Приложения Предприятия я описал Объект Ценности как маленький объект, такой как объект Денег или диапазона дат. Их ключевое свойство заключается в том, что они следуют семантике значений, а не ссылочной семантике.
Вы обычно можете сказать им, потому что их понятие равенства не основано на идентичности, вместо этого два объекта значения равны, если все их поля равны. Хотя все поля равны, вам не нужно сравнивать все поля, если подмножество уникально - например, кодов валюты для объектов валюты достаточно для проверки равенства.
Общая эвристика заключается в том, что ценностные объекты должны быть полностью неизменными. Если вы хотите изменить объект значения, вы должны заменить объект новым и не иметь права обновлять значения самого объекта значения - обновляемые объекты значения приводят к проблемам с наложением алиасов.
В ранней литературе по J2EE термин объект значения использовался для описания другого понятия, которое я называю Data Transfer Object . С тех пор они изменили свое использование и вместо этого используют термин Transfer Object .
Вы можете найти еще несколько хороших материалов по ценным объектам в вики и Dirk Riehle .
Объект передачи данных
Объект передачи данных или DTO - это (анти) шаблон, введенный в EJB. Вместо того чтобы выполнять много удаленных вызовов в EJB, идея заключалась в том, чтобы инкапсулировать данные в объект значения, который можно передать по сети: объект передачи данных. В Википедии есть приличное определение Объект передачи данных :
Объект передачи данных (DTO), ранее известный как объекты значений или VO, - это шаблон проектирования, используемый для передачи данных между подсистемами программных приложений. DTO часто используются вместе с объектами доступа к данным для извлечения данных из базы данных.
Разница между объектами передачи данных и бизнес-объектами или объектами доступа к данным заключается в том, что DTO не имеет никакого поведения, кроме хранения и извлечения своих собственных данных (средства доступа и мутаторы).
В традиционной архитектуре EJB DTO служат двойным целям: во-первых, они решают проблему невозможности сериализации объектных компонентов; во-вторых, они неявно определяют фазу сборки, когда все данные, которые будут использоваться представлением, выбираются и направляются в DTO перед возвратом управления на уровень представления.
Итак, для многих DTO и VO - это одно и то же (но Фаулер использует VO, чтобы обозначить что-то другое, как мы видели). В большинстве случаев они следуют соглашениям JavaBeans и, таким образом, также являются JavaBeans. И все это POJO.