Java Beans

— Ось ти де.

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

Років 10 тому масове поширення набула концепція EJB – EnterpriseJava Beans.

— А що означає Java Beans?

— Bean англійською боб. А Java Beans - це кавові боби (Java - сорт кави). Такий айтішний гумор.

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

Три найвідоміші види EJB-бінів:

Entity Bean – бін, мета якого — зберігати деякі дані. У логіку такого біна вбудований механізм збереження себе та своїх полів у базу даних. Такий об'єкт може бути знищений, а потім відтворений із бази заново. Але, крім зберігання даних, у нього немає жодної логіки.

Session Bean - це функціональний бін. Кожен Session Bean має свою функцію. Один робить одне, інше інше. Такі біни працюють з іншими об'єктами та бінами, а не зі своїми даними.

Session Beans поділяються на дві категорії.

Stateless Session Bean - це бін, який не зберігає у внутрішніх змінних важливих даних, необхідних для його роботи. Такий бін можна знищити, а потім знову створити, і він виконуватиме свою функцію, як і раніше.

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

Але у використанні бінів теж було не все так райдужно, тому незабаром маятник хитнувся у зворотний бік. І розробники почали дедалі частіше використовувати звичайні об'єкти. Їм навіть вигадали спеціальну назву.

POJO (Plain Old Java Object) – старий Традиційний Java-объект. Такі об'єкти не мали якихось суперфункцій і не успадковувалися від супероб'єктів. Найзвичайніші Java-об'єкти.

Коли ти познайомишся з EJB на практиці, ти зрозумієш, у чому різниця. Грубо кажучи, POJO – це ніж, а EJB – це швейцарський ніж, яким можна ще й дзвонити.

— Цікаве порівняння.

— Так, ось що.

Згодом у призначенні об'єктів/класів виникла спеціалізація. Як результат – виділились деякі ролі, об'єкти яких отримали нові назви.

DTO — Data Transfer Object – об'єкт, який створюється з метою використання при транспортуванні даних. Зазвичай до таких об'єктів дві вимоги: а) вміти зберігати дані; б) вміти серіалізуватися. Тобто. їх використовують лише для пересилання даних.

Створив об'єкт, записав у нього потрібні дані з бізнес-логіки, серіалізував у JSON/XML і відправив куди треба. Або навпаки – надійшло повідомлення – десеріалізував його в DTO-об'єкт і витягуй із нього дані.

Entity - це об'єкт, який зберігається в базі даних. Але вони не містять жодної бізнес-логіки. Можна сказати, що це дані бізнес-моделі.

Є ще DAO – Data Access Object. Завдання DAO — зберігати об'єкти в базу та діставати їх із неї. Entity сам такою роботою не займається – він не містить жодної логіки і, отже, не може нічого зберігати нікуди.

Приклад:

UserEntity user = UserDAO.getUserById("1535");
if (user.getAge()>18)
{
 user.setMobilization(true);
 UserDAO.save(user);
}

UserEntity – це клас, який зберігає дані про користувача (User-Entity)
UserDAO – це клас, який дістає дані (об'єкти UserEntity) з бази та зберігає їх туди після змін.

На цьому все.

Хай це і невелика ознайомча лекція, але більше ти зараз все одно не зрозумієш. Кожну з цих тем можна розповідати днями, а EJB – роками.

Але я хочу, щоб ти хоча б уявляв, про що мова, якщо зіткнешся з такими речами у розмові, листуванні, на форумі або на співбесіді.

— Гм. Дякую, Білаабо. Так, гадаю, технічних термінів мені не вистачає. Дуже дякую тобі ще раз.