pojo java что это такое
POJO против Java Beans
Классы POJO
POJO расшифровывается как Plain Old Java Object. Это обычный объект Java, не связанный какими-либо особыми ограничениями, кроме тех, которые налагаются спецификацией языка Java, и не требует какого-либо пути к классам. POJO используются для повышения читабельности и возможности повторного использования программы. POJO получили наибольшее признание, потому что их легко написать и понять. Они были представлены в EJB 3.0 микросистемами Sun.
POJO не должен:
POJOs в основном определяет сущность. Как и в вашей программе, если вам нужен класс Employee, вы можете создать POJO следующим образом:
// Класс POJO сотрудника для представления объекта Сотрудник
public class Employee
private double salary;
// arg-конструктор для инициализации полей
public Employee(String name, String id,
// метод получения имени
public String getName()
// метод получения для id
public String getId()
// метод получения зарплаты
public Double getSalary()
Приведенный выше пример является хорошо определенным примером класса POJO. Как видите, нет ограничений на модификатор доступа к полям. Они могут быть частными, по умолчанию, защищенными или общедоступными. Также нет необходимости включать в него какой-либо конструктор.
POJO — это объект, который инкапсулирует бизнес-логику. На следующем рисунке показан рабочий пример класса POJO. Контроллеры взаимодействуют с вашей бизнес-логикой, которая, в свою очередь, взаимодействует с POJO для доступа к базе данных. В этом примере объект базы данных представлен POJO. Этот POJO имеет тех же членов, что и объект базы данных.
Бобы Java
Бобы — особый тип Pojos. Есть некоторые ограничения на то, чтобы POJO был бобом.
Методы получения и установки имеют некоторые специальные имена в зависимости от имени поля. Например, если именем поля является someProperty, то его получатель предпочтительно будет:
и сеттер будет
Видимость геттеров и сеттеров в общем доступе. Методы получения и установки обеспечивают полное ограничение полей. например, рассмотрите ниже свойство,
Если вы установите публичный видимость возраста, то любой объект может использовать это. Предположим, вы хотите, чтобы возраст не равнялся 0. В этом случае вы не можете контролировать ситуацию. Любой объект может установить его 0. Но с помощью метода setter у вас есть контроль. Вы можете иметь условие в своем методе установки. Точно так же для метода getter, если вы хотите, чтобы, если ваш возраст был равен 0, он возвращал null, вы можете добиться этого, используя метод getter, как в следующем примере:
// Java program to illustrate JavaBeans
class Bean
<
36 уровень. Ответы на вопросы к собеседованию по теме уровня
MVC — это такой паттерн проектирования приложение, при котором приложение разделяется на три отдельные части: модель (model), представление (view) и контроллер (controller). Модель предоставляет данные и реагируется на команды контроллера, изменяя своё состояние. Представление отвечает за отображение данных модели пользователю, реагируя на изменения модели. А контроллер интерпретирует действия пользователя, оповещая модель о необходимости изменений. Таким образом каждый из компонентов этой схемы слабо связан с другими компонентами, за счёт чего достигается гибкость программы. Чаще всего вся бизнес-логика размещается в модели, хотя иногда она содержится и в контроллере. В первом случае модель называют тонкой, в последнем — толстой.
POJO переводится как «объект Java в старом стиле». Их противопоставляют EJB-объектами. Последние следуют специальной конвенции и обычно жёстко привязаны к какому-то конкретному enterprise-фреймворку (например, у них должен быть публичный конструктор без параметров, должен быть геттеры и сеттеры для полей, они должны быть сериализуемыми и т.д.). POJO — это, соответственно, обычный класс, не наследующий ни от каких специальных классов и не реализующий никаких специальных библиотек. Обычно POJO ничего особенного не делает, и содержит только состояние.
Entity Bean — это бин, цель которого хранить некоторые данные. В логику такого бина встроен механизм сохранения себя и своих полей в базу данных. Такой объект может быть уничтожен, а потом воссоздан из базы заново. Но кроме хранения данных у него нет никакой логики. А бин в свою очередь — это особый класс, которые должен выполнять следующие правила:
Очередь (Queue) — это структура данных, работающая по принципу «Первый вошёл — первый вышел». То есть элементы в очередь добавляются с одного конца, а извлекаются — с другого. Deque — это двусторонняя очередь. В этой очереди элементы можно добавлять как в начало, так и в конец, а также брать элементы тоже можно и из начала, и из конца очереди. Соответственно есть методы, которые позволяю положить элемент (это методы add(e) и offer(e)), и есть методы, позволяющие извлечь элемент из очереди (это такие методы, как remove() и poll()). Кроме того, есть методы, которые позволяют просто получить элемент из очереди без его удаления оттуда (это методы element() и peek()). В интерфейсе Deque дополнительно есть методы для добавления элементов в начало и конец очереди, извлечения элементов из начала или конца, а также получения элементов из начала или конца очереди (без их удаления из очереди).
Среди простых реализаций можно отметить ArrayDeque, LinkedList и PriorityQueue. Также существуют много классов в Concurrent Collections, которые реализуют эти два интерфейса (оба сразу или только один из них).
«Мы задавались вопросом, почему люди были так против использования обычных объектов в своих системах, и пришли к выводу, что это произошло потому, что у простых объектов нет причудливого имени. Мы дали им одно, и оно очень хорошо прижилось».
Феномен POJO, скорее всего, получил широкое признание из-за необходимости общего и легко понимаемого термина, который контрастирует со сложными объектными структурами.
СОДЕРЖАНИЕ
Определение
Однако из-за технических трудностей и других причин многие программные продукты или фреймворки, описанные как POJO-совместимые, на самом деле все еще требуют использования предварительно определенных аннотаций для правильной работы таких функций, как постоянство. Идея состоит в том, что если объект (на самом деле класс) был POJO до того, как были добавлены какие-либо аннотации, и вернулся бы в статус POJO, если аннотации были удалены, он все равно может считаться POJO. Тогда базовый объект остается POJO в том смысле, что он не имеет особых характеристик (таких как реализованный интерфейс), которые делают его «специализированным Java-объектом» (SJO или (sic) SoJO).
Контекстные вариации
JavaBeans
Ниже показан пример компонента JavaServer Faces (JSF), имеющего двунаправленную привязку к свойству POJO:
Определение POJO может быть следующим:
Из-за соглашений об именах JavaBean единственная ссылка someProperty может быть автоматически переведена в метод getSomeProperty () (или isSomeProperty (), если свойство имеет логический тип ) для получения значения, а также в метод setSomeProperty ( String) »для установки значения.
Прозрачное добавление услуг
По мере того как проекты, использующие POJO, стали более широко использоваться, возникли системы, которые предоставляют POJO полную функциональность, используемую во фреймворках, и больший выбор в отношении того, какие области функциональности действительно необходимы. В этой модели программист создает не что иное, как POJO. Этот POJO ориентирован исключительно на бизнес-логику и не зависит от (корпоративных) фреймворков. Фреймворки аспектно-ориентированного программирования (АОП) затем прозрачно добавляют сквозные проблемы, такие как постоянство, транзакции, безопасность и т. Д.
Spring была ранним воплощением этой идеи и одной из движущих сил популяризации этой модели.
Пример EJB-компонента, являющегося POJO:
Ниже показан полностью функциональный компонент EJB, демонстрирующий, как EJB3 использует модель POJO:
Как указано, компоненту не нужно расширять какой-либо класс EJB или реализовывать какой-либо интерфейс EJB, а также не нужно содержать никаких аннотаций EJB. Вместо этого программист объявляет во внешнем XML- файле, какие службы EJB следует добавить в компонент:
На практике некоторые люди находят аннотации элегантными, в то время как они считают XML многословным, уродливым и сложным в обслуживании, а другие считают, что аннотации загрязняют модель POJO.
Таким образом, в качестве альтернативы XML многие структуры (например, Spring, EJB и JPA) позволяют использовать аннотации вместо или в дополнение к XML. Ниже показан тот же EJB-компонент, показанный выше, но с добавленной аннотацией. В этом случае XML-файл больше не нужен:
С аннотацией, приведенной выше, bean-компонент больше не является действительно чистым POJO, но поскольку аннотации являются просто пассивными метаданными, у них гораздо меньше вредных недостатков по сравнению с инвазивностью необходимости расширять классы и / или реализовывать интерфейсы. Соответственно, модель программирования по-прежнему очень похожа на чистую модель POJO.
Связанные сокращения
Обычный старый интерфейс Java
В чем разница между JavaBean и POJO?
Я не уверен в разнице. Я использую Hibernate, и в некоторых книгах они используют JavaBean и POJO как взаимозаменяемый термин. Я хочу знать, есть ли разница не только в контексте Hibernate, но и в общих понятиях.
POJO (обычный старый Java-объект) строго не определен. Это Java-объект, который не требует реализации определенного интерфейса или наследования от определенного базового класса, или использования определенных аннотаций для совместимости с данной средой, и может быть любым произвольным (часто относительно простым) Java-объект
Все JavaBean-компоненты являются POJO, но не все POJO-объекты являются JavaBean-компонентами.
Этот термин был придуман, когда Ребекка Парсонс, Джош МакКензи и я готовились к выступлению на конференции в сентябре 2000 года. В этой беседе мы говорили о многих преимуществах кодирования бизнес-логики в обычные объекты Java, а не с использованием Entity Beans. Мы задались вопросом, почему люди были против использования обычных объектов в своих системах, и пришли к выводу, что это потому, что простым объектам не хватает причудливого имени. Итак, мы дали им один, и это очень хорошо завоевало популярность.
POJO: Если класс может быть выполнен с базовым JDK, без какой-либо поддержки сторонних сторонних библиотек, то он называется POJO
JavaBean: Если класс содержит только атрибуты с аксессорами (сеттерами и геттерами), они называются javabeans. Обычно Java-бины не содержат никакой логики бизнес-процессов, а используются для хранения некоторых данных.
Все Javabeans являются POJO, но все POJO не являются Javabeans
Класс pojo может реализовывать интерфейсы и расширять классы, но суперкласс или интерфейс не должны быть технологией / фреймворком.
Класс ABC не реализует или не расширяет технологии / рамки, поэтому это класс pojo.
Класс ABC, расширяющийся от api технологии сервлетов, поэтому это не класс pojo.
Класс ABC реализуется из rmi api, поэтому это не класс pojo.
этот интерфейс является частью языка Java, а не частью технологии / framework. так что это класс pojo.
Здесь поток также является классом языка Java, так что это также класс Pojo.
если класс Test расширяется или реализуется из технологий / инфраструктуры, то ABC также не является классом pojo, поскольку он наследует свойства класса Test. если класс Test не является классом pojo, то класс ABC также не является классом pojo.
теперь этот пункт является исключительным случаем
@Entity это аннотация, заданная hibernate api или jpa api, но все же мы можем назвать этот класс классом pojo. класс с аннотациями, данными из технологии / framework, в этом исключительном случае называется pojo class.
Специальности, перечисленные ниже с указанием причины
В итоге: сходства и различия:
Все бобы JAVA являются POJO, но не все POJO являются бобами JAVA.
Вы видели формальные определения выше, сколько бы они ни стоили.
Но не слишком зацикливайтесь на определениях. Давайте просто посмотрим больше на смысл вещей здесь.
В общем, вы могли видеть Java Beans как просто объекты Java, адаптированные для использования по сети.
С 1995 года в мире программного обеспечения очень много ажиотажа и немало хулиганства.
Как создать POJO?
недавно я начал слышать о «POJOs» (простые старые объекты Java). Я погуглил его, но все еще не понимаю концепцию хорошо. Может ли кто-нибудь дать мне четкое описание POJO?
9 ответов
аббревиатура POJO была реакцией против EJB 2.0, которая требовала нескольких интерфейсов, расширенных базовых классов и множества методов для простых вещей. Некоторые люди, в том числе род Джонсон и Мартин Фаулер, восстали против сложности и искали способ реализовать решения корпоративного масштаба без необходимости писать компоненты EJB.
род Джонсон написал «J2EE без EJBs», написал Spring, повлиял на EJB достаточно, чтобы версия 3.1 выглядела очень похожей на Spring и Hibernate, и получил из нее сладкое IPO от VMWare.
вот пример, который вы можете обернуть вокруг своей головы:
из статьи Википедии, которую я связал с:
в вычислительном программном обеспечении, POJO аббревиатура для простого старого объекта Java. Этот имя используется, чтобы подчеркнуть, что данный объект-это обычный Java-объект, не особый объект, и, в частности, не Предприятие JavaBean
ваш класс, похоже, уже является POJO.
POJO класс действует как Боб, который используется для установки и получения значения.
когда вы ничего не делаете, чтобы сделать свой класс специально разработанным для работы с данной платформой, ORM или другой системой, которая нуждается в специальном классе, у вас есть простой старый объект Java или POJO.
в основном возможны три варианта для отображения цели
при использовании классов pojo разработчику легко сопоставить с базой данных. Классы POJO создаются для базы данных и в то же время классы value-objects создаются с помощью методов getter и setter, которые легко удерживают содержимое.
Итак, с целью отображение между java с базой данных, value-objects и POJO классов реализованы.
Как правило, POJO не связан с каким-либо ограничением, и любой объект Java можно назвать POJO, но есть некоторые направления. Четко определенный POJO должен следовать ниже указаниям.
и согласно спецификации языка Java, POJO не должен иметь
однако разработчики и фреймворки описывают POJO по-прежнему требует использования заранее определенных аннотаций для реализации таких функций, как персистентность, декларативное управление транзакциями и т. д. Таким образом, идея заключается в том, что если объект был POJO до добавления каких-либо аннотаций, он вернется в статус POJO, если аннотации будут удалены, то его все еще можно считать POJO.
JavaBean-это особый вид POJO, который сериализуется, имеет конструктор без аргументов и разрешает доступ к свойствам с помощью методов getter и setter, которые следуют простому соглашению об именах.