Что именно означает термин «Простой старый Java-объект» (POJO)?

Question

Что означает термин Простой старый Java-объект (POJO) ? Я не мог найти ничего достаточно объяснительного.

Страница Википедии POJO говорит, что POJO - это обычный Java-объект, а не специальный объект. Теперь, что делает или что не делает и не делает объект особенным в Java?

На приведенной выше странице также сказано, что POJO не должен расширять заранее заданные классы, реализовывать заранее заданные интерфейсы или содержать заранее заданные аннотации. Означает ли это также, что POJO не разрешается реализовывать интерфейсы, такие как Serializable, Comparable, или классы, такие как Applets, или любые другие пользовательские классы / интерфейсы?

Кроме того, означает ли приведенная выше политика (без расширения, без реализации), что нам не разрешено использовать какие-либо внешние библиотеки?

Где именно используются POJO?

РЕДАКТИРОВАТЬ: Чтобы быть более точным, я могу расширить / реализовать классы / интерфейсы, которые являются частью Java или каких-либо внешних библиотек?

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки: вики source2

Answer 2

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

Answer 3

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

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

Answer 4

Простой старый объект Java:)

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

ИМХО Вики-страница довольно понятна.В нем не сказано, что POJO не может иметь аннотации / интерфейсы.

Answer 7

Что означает термин «Простой старый Java-объект» (POJO)?

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

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

Сущности bean-компонентов наиболее полезны при использовании Container Managed Постоянство (CMP) ...

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

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

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

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

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

Answer 8

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

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

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