Що означає гідратація об'єкта?

Коли хтось говорить про гідратацію об’єкта, що це означає?

У Інтернеті я бачу проект Java під назвою Hydrate, який перетворює дані між різними представленнями (RDMS в OOPS в XML). Це загальне значення гідратації об'єкта; перетворювати дані між уявленнями? Чи може це означати реконструкцію ієрархії об’єктів із збереженого подання?

Що стосується більш загального терміна гідрат

Гідратація об'єкта - це об'єкт, який існує в пам'яті, який ще не містить даних про домен ("справжні" дані), а потім заповнення його даними домену (наприклад, з бази даних, мережі або з файлу система).

З коментарів Еріка Робертсона до цієї відповіді:

десеріалізація == інстанція + гідратація

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

Більш детально про концепцію гідратації дивіться відповідь Еріка Робертсона на це ж запитання.

Стосовно проекту Java називається гідрат

Ви конкретно запитали про цю рамку, тому я розглядав її.

Як найкраще я можу сказати, я не думаю, що цей проект використовував слово "гідрат" в дуже загальному значенні. Я бачу його вживання в назві як приблизний синонім «серіалізація». Як було пояснено вище, це використання не зовсім точне:

Дивіться: http://en.wikipedia.org/wiki/Серіялізація

переведення структур даних або стану об'єкта у формат, який може бути збережений [...] та реконструйований пізніше в тому ж чи іншому комп’ютерному середовищі.

Я не можу знайти причину їхнього імені безпосередньо у FAQ щодо гідратів , але я отримав підказки щодо їх наміру. Я думаю, що вони вибрали назву "Hydrate", тому що призначення бібліотеки схоже на популярну звукову систему Hibernate , але вона була розроблена з точно протилежним робочим процесом.

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

Метафорично кажучи, що стосується назви цієї бібліотеки: Гідрат - це як "зробити щось готове до вживання" (наприклад, повторне зволоження сушених продуктів ). Це метафорична протилежність режиму сплячки , що більше нагадує "відкласти щось на зиму" (як сплячка тварин ).

Рішення про назву бібліотеки Hydrate, наскільки я можу сказати, не стосувалося загального терміна комп'ютерного програмування «гідрат».

Використовуючи загальний термін "гідрат" комп'ютерного програмування, оптимізація продуктивності зазвичай є мотивацією (або налагодженням існуючих оптимізацій). Навіть якщо бібліотека підтримує деталізований контроль над тим, як і як об’єкти заповнюються даними, тимчасові показники та ефективність, здається, не є основною мотивацією для імені або функціональності бібліотеки. Бібліотека, здається, більше стурбована тим, що дозволяє чітке відображення та збереження схем.

Під гідратацією розуміється процес заповнення об’єкта даними. Об'єкт, який ще не був гідратований, був створений екземпляром і являє собою сутність, яка має дані, але дані ще не завантажені в об'єкт. Це те, що робиться з міркувань продуктивності.

Крім того, термін гідратація використовується при обговоренні планів завантаження даних з баз даних або інших джерел даних. Ось кілька прикладів:

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

Крім того, є деякі ORM, такі як Doctrine, які не гідрують об'єкти під час їх інстанції, а лише тоді, коли доступ до даних в цьому об'єкті. Це один метод, який допомагає не завантажувати дані, які не збираються використовувати.

Хоча це дещо зайве просторіччя, як згадувала Мерлін, у моєму досвіді це стосується лише заповнення / заселення об'єкта, а не інстанції / створення його, тому це корисне слово, коли потрібно бути точним.

Це досить старе питання, але, схоже, все ще виникає плутанина щодо значення наступних термінів. Сподіваємось, це буде неоднозначним.

Гідрат

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

Використовуючи JavaScript як приклад:

const obj = {}; // empty object
const data = { foo: true, bar: true, baz: true };

// Hydrate "obj" with "data" 
Object.assign(obj, data); 
console.log(obj.foo); // true
console.log(obj.bar); // true
console.log(obj.baz); // true

Все, що додає значення, objце "зволоження" цього. Я просто використовую Object.assign()в цьому прикладі.

Оскільки терміни "серіалізувати" та "десеріалізувати" також згадувалися в інших відповідях, ось приклади, які допомагають розмежувати значення цих понять від гідратації:

Серіалізувати

console.log(JSON.stringify({ foo: true, bar: true, baz: true }));

Десеріалізувати

console.log(JSON.parse('{"foo":true,"bar":true,"baz":true}'));