Что означает термин Plain Old Java Object (POJO)?

Ответ 1

Обычный старый объект Java Это имя используется для того, чтобы подчеркнуть, что данный объект является обычным Java-объектом, а не специальным объектом, таким как те, которые определены каркасом EJB 2.

класс A {}
класс B расширяет/реализует C {}

Примечание: B не является POJO, когда C является видом распределенного класса framework или ifc. например javax.servlet.http.HttpServlet, javax.ejb.EntityBean или J2EE extn и не является сериализуемым/сопоставимым. Поскольку сериализуемые/сопоставимые действительны для POJO.

Здесь A - простой объект, который является независимым. B является специальным obj, так как B расширяет/реализует C. Таким образом, объект B получает некоторое значение из C и B, ограничивает выполнение правил из C. и B является плотно связанным с распределенной структурой. Следовательно, объект B не является POJO из его определения.

Код с помощью ссылки на объект класса Object не должен знать ничего о его типе и может использоваться со многими фреймами.

Таким образом, POJO не должен: 1) расширять заданные классы и 2) реализовывать заданные интерфейсы.

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

POJO исключительно фокусируется на бизнес-логике и не имеет зависимости от (корпоративных) фреймворков. Это означает, что у него есть код для бизнес-логики, но как создается этот экземпляр, к какому сервису (EJB..) принадлежит этот объект и каковы его особые характеристики (Stateful/Stateless), который он принимает, будут решены с помощью внешних xml файл.

Пример 1: JAXB - это служба, представляющая объект Java как XML; Эти java-объекты просты и выходят с помощью конструкторов-устроителей и сеттеров по умолчанию.

Пример 2: Hibernate, где для представления таблицы будет использоваться простой класс java. столбцы будут его экземплярами.

Пример 3: службы REST. В службах REST мы будем иметь уровень обслуживания и уровень Dao для выполнения некоторых операций над БД. Поэтому у Dao будут конкретные запросы и операции с поставщиками. Уровень обслуживания будет отвечать за вызов, который должен выполнять DAO для выполнения операций БД. Создание или обновление API (методов) DAO будет принимать POJO в качестве аргументов и обновлять POJO и вставлять/обновлять в DB. Эти POJO (класс Java) будут иметь только состояния (переменные экземпляра) каждого столбца и его геттеры и сеттеры.

На практике некоторые люди находят аннотации элегантными, в то время как они рассматривают XML как многословные, уродливые и трудноподдерживаемые, а другие - аннотации, которые загрязняют модель POJO. Таким образом, в качестве альтернативы XML многие фреймворки (например, Spring, EJB и JPA) позволяют использовать аннотации вместо или в дополнение к XML:

Преимущества:
Развязка кода приложения из инфраструктурных инфраструктур является одним из многих преимуществ использования POJO. Использование POJO в будущем подтвердит вашу бизнес-логику приложения, отделив ее от изменчивых, постоянно меняющихся инфраструктурных инфраструктур. Переход на новую версию или переход на другую структуру становится проще и менее рискованно. POJO также упрощают тестирование, что упрощает и ускоряет разработку. Ваша бизнес-логика будет более понятной и простой, поскольку она не будет запутана с кодом инфраструктуры

Ссылки: wiki source2

Ответ 2

По словам Мартина Фаулера, он и некоторые другие придумали это как способ описать что-то, что было стандартным классом, в отличие от EJB и т.д.

Ответ 3

Использование термина подразумевает то, что он должен вам сказать. Если, например, инфраструктура внедрения зависимостей говорит вам, что вы можете вводить POJO в любое другое ПОЖО, они хотят сказать, что вам не нужно ничего особенного: нет необходимости выполнять какие-либо контракты с вашим объектом, реализовывать любые интерфейсы или расширить специальные классы. Вы можете просто использовать то, что у вас уже есть.

ОБНОВЛЕНИЕ. Чтобы привести еще один пример: в то время как Hibernate может сопоставить любое POJO (любой созданный объект) с таблицами SQL, в Core Data (Objective C на iPhone) ваши объекты должны расширять NSManagedObject в порядке чтобы система могла сохранять их в базе данных. В этом смысле Core Data не может работать с любым POJO (или, скорее, POOCO = PlainOldObjectiveCObject), в то время как Hibernate может. (Я не мог бы на 100% правильно восстановить основные данные, так как я только начал его подбирать. Любые подсказки/исправления приветствуются:-)).

Ответ 4

Обычный старый объект Java:)

Ну, ты говоришь, что все это ужасные ограничения.

В обычном контексте, где используется POJO, это больше похоже на преимущество:

Это означает, что любая библиотека /API, с которой вы работаете, отлично согласна работать с объектами Java, которые каким-либо образом не были обработаны или обработаны каким-либо образом, то есть вам не нужно делать ничего особенного, чтобы заставить их работать.

Например, XStream XML-процессор будет (я думаю) счастливо сериализовать Java-классы, которые не реализуют интерфейс Serializable. Это плюс! Многие продукты, которые работают с объектами данных, используются для принудительного внедрения SomeProprietaryDataObject или даже расширения класса AbstractProprietaryDataObject. Многие библиотеки ожидают поведения bean, т.е. Получателей и сеттеров.

Как правило, все, что работает с POJO, также будет работать с не-так-PO-JO. Таким образом, XStream, конечно же, также сериализует классы Serializable.

Ответ 5

POJO - простой обычный Java-объект - по сравнению с чем-то, что требуется для Enterprise Edition (J2EE) (beans и т.д.).

POJO на самом деле не является жестким определением и более ручным способом описания "нормальных" не-корпоративных объектов Java. Независимо от того, использует ли внешняя библиотека или инфраструктура объект POJO или нет, это выглядит в глазах наблюдателя, в значительной степени зависящим от библиотеки/структуры WHAT, хотя я бы рискнул предположить, что структура сделает что-то меньшее из POJO

Ответ 6

Вся суть POJO - это простота, и вы, кажется, предполагаете ее нечто более сложное, чем кажется.

Если библиотека поддерживает POJO, это означает, что объект любого класса допустим. Это не означает, что POJO не может иметь аннотации/интерфейс или что они не будут использоваться, если они есть, но это не является обязательным требованием.

IMHO Вики-страница достаточно ясна. Он не говорит, что POJO не может иметь аннотации/интерфейсы.

Ответ 7

Обычный старый объект Java (POJO), содержащий всю бизнес-логику для вашего расширения.

Exp. Pojo, который содержит единственный метод

public class Extension {
   public static void logInfo(String message) {
      System.out.println(message);
   }
}

Ответ 8

Что означает термин Plain Old Java Object (POJO)?

POJO был придуман Мартином Фаулером, Ребеккой Парсонс и Джошем Маккензи, когда они готовились к разговору на конференции в сентябре 2000 года. Мартин Фаулер в Шаблоны предприятия Архитектура приложений объясняет, как реализовать шаблон модели домена в Java. После перечисления некоторых недостатков использования EJB Entity Beans:

Всегда есть много тепла, когда люди говорят о разработка модели домена в J2EE. Многие учебные материалы и Вводные J2EE-книги предполагают, что вы используете сущность beans для разработки, но есть некоторые серьезные проблемы с этим подходом, по крайней мере, с текущей (2.0) спецификацией.

Entity beans наиболее полезны при использовании управляемых контейнеров Стойкость (CMP)...

Объект beans не может быть повторно включен. То есть, если вы вызываете из одного entity bean в другой объект, этот другой объект (или любой объект звонки) не могут перезвонить в первый объект bean...

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

Для запуска с сущностью beans вам нужен контейнер и база данных связанный. Это увеличит время сборки, а также увеличит время выполнять тестовые прогоны, поскольку тесты должны выполняться в отношении базы данных. Сущность beans также сложна для отладки.

В качестве альтернативы он предложил использовать регулярные объекты Java для реализации модели домена:

Альтернативой является использование обычных объектов Java, хотя это часто вызывает удивленную реакцию - удивительно, как много людей думают, что вы не можете запускать обычные объекты Java в контейнере EJB. Я пришел вывод о том, что люди забывают о обычных объектах Java, потому что у них нет причудливого имени. Вот почему, готовясь к разговору в 2000 году Ребекка Парсонс, Джош Маккензи, и я дал им один: POJO (простые старые объекты Java). Доменную модель POJO легко собрать, быстро создается, может запускаться и тестироваться вне контейнера EJB, и независимо от EJB (возможно, почему поставщики EJB не поощряют вас использовать их).