Різниця між DTO, VO, POJO, JavaBeans?


584

Бачили кілька подібних питань:

Чи можете ви також, будь ласка, розкажіть мені про контексти, в яких вони використовуються? Або мета їх?


1
POJO поставляється без обмежень, коли як javabeans надходить з обмеженнями, згаданими вище
exexzian

Відповіді:


848

JavaBeans

JavaBean - клас, який дотримується конвенцій JavaBeans , визначених Sun. У Вікіпедії є досить хороший підсумок того, що таке JavaBeans :

JavaBeans - це програмні компоненти для багаторазового використання для Java, якими візуально можна керувати в інструменті для побудови. Практично це класи, написані мовою програмування Java, що відповідають певній умові. Вони використовуються для інкапсуляції багатьох об'єктів в один об'єкт (квасоля), так що вони можуть передаватися навколо як один об'єкт бобів, а не як кілька окремих об'єктів. JavaBean - це об'єкт Java, який можна серіалізувати, має нульовий конструктор і дозволяє отримати доступ до властивостей за допомогою методів getter та setter.

Для того, щоб функціонувати як клас JavaBean, клас об’єктів повинен дотримуватися певних умов щодо іменування методів, побудови та поведінки. Ці конвенції дозволяють мати інструменти, які можуть використовувати, використовувати повторно, замінювати та підключати JavaBeans.

Необхідні умови:

  • Клас повинен мати публічний конструктор за замовчуванням. Це дозволяє легко інстанціювати в межах редагування та активації.
  • Властивості класу повинні бути доступними за допомогою методу get, set та інших методів (так званих методів accessor та mutator), дотримуючись стандартної угоди про іменування. Це дозволяє легко автоматизовано перевіряти та оновлювати стан бобів у рамках, багато з яких містять спеціальні редактори для різних типів властивостей.
  • Клас повинен бути серіалізаційним. Це дозволяє програмам та рамкам надійно зберігати, зберігати та відновлювати стан бобів таким чином, що це не залежить від віртуального комп'ютера та платформи.

Оскільки ці вимоги значною мірою виражаються як конвенції, а не через реалізацію інтерфейсів, деякі розробники розглядають JavaBeans як звичайні старі об’єкти Java, які слідують певним умовам іменування.

POJO

Простий старий об’єкт Java або POJO - це термін, спочатку введений для позначення простого об'єкта Java, який не реалізує жодного javax.ejbінтерфейсу, на відміну від важкої ваги EJB 2.x (особливо Entity Beans, Beatless Session Beans - це не такий вже й поганий IMO). Сьогодні цей термін використовується для будь-якого простого об'єкта без зайвих речей. Знову ж таки, Вікіпедія робить хорошу роботу у визначенні POJO :

POJO - абревіатура для Plain Old Java Object. Назва використовується для підкреслення того, що спірний об'єкт є звичайним об'єктом Java, а не спеціальним об'єктом і, зокрема, не Enterprise JavaBean (особливо перед EJB 3). Цей термін було введено Мартіном Фаулером, Ребеккою Парсонс та Джошем Макензі у вересні 2000 року:

"Ми поцікавились, чому люди настільки проти використання звичайних об'єктів у своїх системах і зробили висновок, що це тому, що простим об'єктам не вистачає фантазійної назви. Тож ми дали їм один, і це дуже приємно".

Цей термін продовжує схему старих термінів для технологій, які не використовують фантазійних нових функцій, таких як POTS (Plain Old Telephone Service) в телефонії та PODS (Plain Old Data Structures), які визначені в C ++, але використовують лише функції мови C, та POD (звичайна стара документація) в Perl.

Цей термін, швидше за все, отримав широке визнання через необхідність використання загального і легко зрозумілого терміна, який контрастує зі складними рамками об'єктів. JavaBean - POJO, який можна серіалізувати, має конструктор без аргументів і дозволяє отримати доступ до властивостей за допомогою методів getter та setter. Enterprise JavaBean - це не один клас, а ціла модель компонентів (знову ж, EJB 3 зменшує складність Enterprise JavaBeans).

Оскільки конструкції, що використовують POJO, стали все частіше використовуватися, виникли системи, які надають POJO деяку функціональність, що використовується в рамках, і більше можливостей щодо того, які саме області функціональності потрібні. Зимовий режим і Весна - приклади.

Ціннісний об’єкт

Об'єкт значення або VO - такий об'єкт, java.lang.Integerякий містить значення (отже, об'єкти значення). Для більш формального визначення я часто звертаюся до опису Мартіна Фаулера Значення Об'єкта :

У «Шаблонах архітектури корпоративних додатків» я описав Value Object як невеликий об’єкт, такий як об’єкт «Гроші» чи «діапазон дат». Їх ключовою властивістю є те, що вони слідують семантиці значення, а не еталонній семантиці.

Зазвичай їх можна сказати, оскільки їхнє поняття рівності не базується на ідентичності, натомість два ціннісні об'єкти рівні, якщо всі їхні поля рівні. Хоча всі поля рівні, вам не потрібно порівнювати всі поля, якщо підмножина унікальна - наприклад, коди валют для валютних об'єктів достатньо для перевірки рівності.

Загальним евристичним є те, що ціннісні об'єкти повинні бути повністю незмінні. Якщо ви хочете змінити об'єкт значення, вам слід замінити об'єкт на новий і не дозволяти оновлювати значення самого об'єкта значення - об’єкти, що можна оновити, призводять до виникнення проблем.

Рання література J2EE використовувала об'єкт значення терміна, щоб описати інше поняття, як я називаю " Об'єкт передачі даних" . З тих пір вони змінили своє використання і натомість використовують термін " Передача" .

Ви можете знайти ще кілька хороших матеріалів про цінні об’єкти на вікі та від Дірка Ріле .

Об'єкт передачі даних

Об'єкт передачі даних або DTO - це (анти) шаблон, що вводиться з EJB. Замість того, щоб виконувати багато віддалених дзвінків на EJB, ідея полягала в тому, щоб інкапсулювати дані в об'єкт значення, який можна перенести через мережу: Об'єкт передачі даних. У Вікіпедії є гідне визначення об’єкта передачі даних :

Об'єкт передачі даних (DTO), раніше відомий як об'єкти цінності або VO, є схемою проектування, що використовується для передачі даних між підсистемами програмного забезпечення. DTO часто використовуються спільно з об'єктами доступу до даних для отримання даних із бази даних.

Різниця між об'єктами передачі даних та бізнес-об'єктами або об'єктами доступу до даних полягає в тому, що DTO не має жодної поведінки, крім зберігання та пошуку власних даних (аксесуарів та мутаторів).

У традиційній архітектурі EJB, DTO служать подвійним призначенням: по-перше, вони вирішують проблему, що сутність об'єктів не піддається серіалізації; по-друге, вони неявно визначають фазу складання, коли всі дані, які будуть використовуватися представленням даних, збираються та розміщуються в DTO перед поверненням управління до рівня представлення.


Отже, для багатьох людей DTO і VO - це одне і те ж (але Фоулер використовує VO для того, щоб означати щось інше, як ми бачили). Здебільшого вони дотримуються конвенцій JavaBeans і, таким чином, також є JavaBeans. І всі - POJO.


1
Отже, якщо у мене є клас зручності, створений саме для передачі неспоріднених даних, таких як цей, class SomeClass { public String foo;public String bar; }всередині класу з великою кількістю складної логіки, напевно це не JavaBean, він не може бути VO, оскільки він є змінним, чи може це бути DTO? але він не орієнтований на віддалений виклик будь-якого типу. Чи може це вважатися POJO?
Хайме Хаблутцель

3
@ user2601512: все одно це буде Bean. : P Немає нічого поганого в поведінці Біна - насправді, це дуже очікується. Якщо він не робить нічого іншого, це в основному DTO.
cHao

7
@xSNRG: Частково тому, що він демонструє об'єкти на дані, на які діє інший код. Це крок назад з точки зору ОО, коли об'єкти діють і повинні відповідати за свою державу. DTO іноді є гідним рішенням, якщо ви насправді просто передаєте дані - звідси і назва - але інкапсуляція в основному виходить з вікна, і ви зазвичай втрачаєте будь-які гарантії дійсності / послідовності, які могли б забезпечити реальний об'єкт.
cHao

1
@KumaresanPerumal: Ви можете, якщо хочете. Але модель відрізняється від рівня даних і має різні цілі та правила. Рівень даних зазвичай потребує всього викладеного та довільного встановлення, і модель в ідеалі хоче приховати дані та застосувати інваріанти. Ви хочете використовувати об'єкти моделі для зберігання, вам доведеться йти на компроміс з одного чи іншого боку.
cHao

1
@KumaresanPerumal: рівень даних є для зберігання та отримання даних. Для цього йому потрібен повний доступ до будь-якого об'єкта, який містить дані, оскільки пошук означає встановлення значень в об'єкті десь. Але модель керує цими даними в системі і пов'язана з принципами ОО, як інкапсуляція - ідея, що об'єкти повинні підтримувати контроль над своїм внутрішнім станом і не мати іншого коду, що возиться зі своїми внутрішніми. DTO можуть усунути цей проміжок; рівень даних може отримати доступ до них за власним бажанням, і модель не повинна відмовлятися від управління.
cHao

66

DTO проти VO

DTO - Об'єкти передачі даних - це просто контейнери даних, які використовуються для транспортування даних між шарами та ярусами.

  • В основному вона містить атрибути. Ви навіть можете використовувати загальнодоступні атрибути без геттерів та сетерів.
  • Об'єкти передачі даних не містять жодної логіки бізнесу.

Аналогія:
проста реєстраційна форма з атрибутами ім'я користувача, пароля та електронної пошти.

  • Коли ця форма буде подана у файл RegistrationServlet, ви отримаєте всі атрибути від шару перегляду до бізнес-шару, де ви передасте атрибути до Java-бобів, а потім до DAO або шару збереження.
  • DTO допомагає транспортувати атрибути від рівня перегляду до бізнес-рівня та, нарешті, до рівня стійкості.

DTO в основному використовувався для ефективного транспортування даних по мережі, можливо, це навіть з JVM в інший JVM.

ЗНО часто java.io.Serializable - для передачі даних через JVM.

VO - ціннісний об’єкт [1] [2] являє собою фіксований набір даних і схожий на перерахунок Java. Ідентичність ціннісного об’єкта базується не на їхньому стані, а не на їх об'єктній ідентичності та є незмінною. Справжнім прикладом світу можуть бути Color.RED, Color.BLUE, SEX.FEMALE тощо.

POJO проти JavaBeans

[1] Java-Beanness POJO полягає в тому, що всі його приватні атрибути доступні через публічні геттери та сетери, які відповідають конвенціям JavaBeans. напр

    private String foo;
    public String getFoo(){...}
    public void setFoo(String foo){...}; 

[2] JavaBeans повинен реалізувати Serializable і мати конструктор без аргументів, тоді як у POJO немає цих обмежень.


Вибачте за коментар sooooo пізно, але я дізнаюся про відмінності між ними, і у мене є питання. Що робити, якщо у мене є клас Java Bean, але з іншими методами, такими як doSomething (). Що це за клас? З повагою
jscherman

@srinivas Чому ми не можемо передати дані в об'єкт DAVAIN або MODEL java? Але я використовую МОДЕЛЬ без DTO. будь ласка, поясніть мені коротко. спасибі
Kumaresan Perumal

46

В основному,

DTO: "Об'єкти передачі даних" можуть пересуватись між окремими шарами в архітектурі програмного забезпечення.

VO: "Об'єкти цінності" містять такі об'єкти, як Integer, Money тощо.

POJO: Простий старий об'єкт Java, який не є спеціальним об'єктом.

Java Beans: вимагає, Java Classщоб підлягає серіалізації, мати no-argконструктор та геттер та сетер для кожного поля


Ці описи переважно неправильні / неповні.
cellepo

24

Java Beans - це не те саме, що EJB.

Специфікація JavaBeans в Java 1.0 - це спроба Sun дозволити маніпулювати об'єктами Java в IDE, схожий на VB. Існували правила, встановлені для об'єктів, які кваліфікуються як "Квасоля Java":

  1. Конструктор за замовчуванням
  2. Геттери та сетери для членів приватних даних, які дотримувались правильної конвенції про іменування
  3. Серіалізація
  4. Можливо, інших, про які я забуваю.

EJB прийшли пізніше. Вони поєднують розподілені компоненти та транзакційну модель, що працює в контейнері, який управляє потоками, об'єднанням, життєвим циклом та надає послуги. Вони далеко від Java Beans.

DTO з'явилися в контексті Java, оскільки люди з'ясували, що специфікація EJB 1.0 надто "балакана" з базою даних. Замість того, щоб робити зворотну пряму для кожного елемента даних, люди збирають їх у Java Beans оптом і відправляють їх навколо.

POJO були реакцією проти EJB.


1
Я помилявся і вважав за краще видалити своє повідомлення. Дякуємо за виправлення Хочу зазначити, що значення POJO змінилося деякий час тому. По-перше, вони створені лише з приватних об'єктів та їхніх приладів. Тепер ми вважаємо POJO класом з анотаціями, реалізацією та розширенням інших класів тощо
sinuhepop

Що з VO, як запитало питання? Це не відповідь, поки вона не відповідає на повне запитання
cellepo

4

POJO : Це файл Java (клас), який не розширює та не реалізує жоден інший файл (клас) java.

Бін : це файл Java (клас), у якому всі змінні є приватними, методи є загальнодоступними, а для доступу до змінних використовуються відповідні getters та setters.

Нормальний клас : це файл java (клас), який може складатися із загальнодоступних / приватних / за замовчуванням / захищених змінних і який може або не може поширювати чи реалізовувати інший файл Java (клас).


Що з VO, як запитало питання? Це не відповідь, поки вона не відповідає на повне запитання
cellepo

1

Перша розмова про

Нормальний клас - це означає, що будь-який клас визначає, що це звичайно в java, це означає, що ви створюєте різні типи властивостей методу тощо.
Bean - Bean - це нічого, це лише об'єкт цього конкретного класу, використовуючи цей bean, ви можете отримати доступ до свого класу java так само, як і до об'єкта. .

а після цього поговоріть про останній POJO

POJO - POJO - це клас, який не має жодних послуг, у нього є лише конструктор за замовчуванням і приватна власність, а також ця властивість для встановлення відповідних значень методів встановлення та отримання. Це коротка форма простого об'єкта Java.


Що з VO, як запитало питання? Це не відповідь, поки вона не відповідає на повне запитання
cellepo

1
  • Об'єкт значення : Використовуйте, коли потрібно вимірювати рівність об'єктів на основі значення об'єктів.
  • Об'єкт передачі даних: передайте дані з декількома атрибутами в один кадр від клієнта до сервера по всьому шару, щоб уникнути декількох викликів на віддалений сервер.
  • Простий старий об’єкт Java : це як простий клас, властивості якого, громадський конструктор no-arg. Як ми заявляємо для суб'єкта JPA.

різниця між значенням-об'єктом-шаблоном-передачею-шаблоном передачі даних

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.