Чому Hibernate не вимагає конструктора аргументів?

Конструктор no-argument є вимогою (такі інструменти, як Hibernate, використовують відображення цього конструктора для створення екземплярів об'єктів).

Я отримав цю хвилеподібну відповідь, але хтось може пояснити далі? Дякую

Hibernate і код загалом, який створює об'єкти за допомогою відображення, використовуючи Class<T>.newInstance()для створення нового примірника ваших класів. Цей метод вимагає, щоб громадський конструктор без аргументів мав змогу створювати об'єкт. Для більшості випадків використання конструктор no-arg не є проблемою.

Є хаки на основі серіалізації, які можуть обійти відсутність конструктора без аргументів, оскільки серіалізація використовує jvm магію для створення об'єктів без виклику конструктора. Але це доступно не для всіх віртуальних машин. Наприклад, XStream може створювати екземпляри об'єктів, у яких немає загальнодоступного конструктора no-arg, але лише запускаючи в так званому "розширеному" режимі, який доступний лише для певних віртуальних машин. (Докладні відомості див. За посиланням.) Дизайнери Hibernate, безумовно, вирішили підтримувати сумісність з усіма віртуальними машинами, тому уникають подібних хитрощів, і використовують офіційно підтримуваний метод відображення, що Class<T>.newInstance()вимагає конструктора без аргументів.

Hibernate створює екземпляри ваших об’єктів. Тому вона повинна мати можливість створити їх екземпляр. Якщо немає конструктора no-arg, Hibernate не знатиме, як його створити, тобто який аргумент передавати.

Документація про сплячий режим говорить:

4.1.1. Реалізувати конструктор без аргументів

Усі постійні класи повинні мати конструктор за замовчуванням (який може бути непублічним), щоб Hibernate міг створити їх за допомогою екземпляра Constructor.newInstance(). Рекомендується мати конструктор за замовчуванням з принаймні видимістю пакету для генерації проксі-серверів виконання в режимі глибокого сну.

Ем, вибачте всіх, але Hibernate не вимагає, щоб ваші класи мали конструктор без параметрів. Специфікація JPA 2.0 вимагає цього, і це дуже кульгаво від імені JPA. Інші рамки, такі як JAXB, також вимагають цього, що також дуже кульгаво від імені цих фреймворків.

(Насправді, JAXB нібито дозволяє виробляти юридичні заводи, але він наполягає на створенні цих заводів самостійно, вимагаючи, щоб вони мали, - думаю, конструктор без параметрів , який у моїй книзі так само хороший, як не дозволяють заводам; наскільки кульга це !)

Але сплячого не вимагає такого.

Hibernate підтримує механізм перехоплення (див. "Перехоплювач" у документації ), який дозволяє створювати екземпляри об'єктів з будь-якими параметрами конструктора, які їм потрібні.

В основному, ви робите те, що при налаштуванні сплячого режиму ви передаєте йому об'єкт, що реалізує org.hibernate.Interceptorінтерфейс, і в сплячку потім буде застосовуватися instantiate()метод цього інтерфейсу, коли він потребує нового екземпляра вашого об'єкта, тому ваша реалізація цього методу може newваші предмети будь-яким способом вам подобається.

Я зробив це в проекті, і це працює як шарм. У цьому проекті я роблю речі через JPA, коли це можливо, і використовую такі функції Hibernate, як перехоплювач, лише коли у мене немає іншого варіанту.

Hibernate, здається, дещо невпевнений у цьому, оскільки під час запуску він видає інформаційне повідомлення для кожного з моїх класів сутності, повідомляючи мені INFO: HHH000182: No default (no-argument) constructor for classі class must be instantiated by Interceptor, але потім пізніше я створюю їх за допомогою перехоплювача, і це задоволено.

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

Зимова сплячка - це структура ORM, яка підтримує стратегію доступу до поля чи власності. Однак воно не підтримує побудову на основі конструкторів - можливо, що б ви хотіли? - через такі проблеми, як

1º Що відбувається, якщо ваш клас містить багато конструкторів

public class Person {

    private String name;
    private Integer age;

    public Person(String name, Integer age) { ... }
    public Person(String name) { ... }
    public Person(Integer age) { ... }

}

Як бачите, ви вирішуєте проблему невідповідності, оскільки Hibernate не може припустити, який конструктор слід викликати. Наприклад, припустимо, вам потрібно отримати збережений об'єкт Person

Person person = (Person) session.get(Person.class, <IDENTIFIER>);

Який конструктор слід викликати в сплячий режим для отримання об’єкта Person? Бачиш ?

2º І, нарешті, за допомогою відображення Hibernate може створити клас за допомогою свого конструктора no-arg. Тож коли ви телефонуєте

Person person = (Person) session.get(Person.class, <IDENTIFIER>);

Hibernate створить екземпляр вашого об’єкта Person наступним чином

Person.class.newInstance();

Який згідно з документацією API

Клас створюється як екземпляр нового виразу з порожнім списком аргументів

Мораль розповіді

Person.class.newInstance();

схожий на

new Person();

Більш нічого

Насправді ви можете створювати класи, які не мають конструктора 0-args; Ви можете отримати список конструкторів класу, вибрати один і викликати його з фіктивними параметрами.

Хоча це можливо, і, мабуть, це спрацювало б і не було б проблематично, доведеться погодитися, що це досить дивно.

Побудова об'єктів так, як робить Hibernate (я вважаю, що він викликає конструктор 0-arg, а потім, ймовірно, змінює поля екземпляра безпосередньо за допомогою Reflection. Можливо, він знає, як викликати сетерів), дещо суперечить тому, як об'єкт повинен бути побудований в Java - викликайте конструктор з відповідними параметрами, щоб новий об'єкт був потрібним об'єктом. Я вважаю, що інстанціювання об'єкта, а потім його мутування дещо "анти-Java" (або я б сказав, анти-чиста теоретична Java) - і, безумовно, якщо це зробити за допомогою прямого польового маніпулювання, це буде інкапсуляцією і всіма цими фантазійними інкапсуляційними матеріалами .

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

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

Hibernate потребує створення екземплярів у результаті ваших запитів (за допомогою відображення), Hibernate для цього покладається на конструктор no-arg з сутностями, тому вам потрібно надати конструктор no-arg. Що незрозуміло?

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

Багато ORM та серіалізатори потребують конструкторів без параметрів, оскільки параметризовані конструктори через відображення дуже крихкі, а конструктори без параметрів забезпечують як стабільність додатку, так і контроль над поведінкою об'єкта розробнику.

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

Але якщо ви використовуєте метод session.load (), ви зіткнетеся з InstantiationException з lib генератора проксі-сервера через відсутність конструктора.

Цей хлопець повідомив про подібну ситуацію:

http://kristian-domagala.blogspot.com/2008/10/proxy-instantiation-problem-from.html

Перегляньте цей розділ специфікації мови Java, який пояснює різницю між статичними та нестатичними внутрішніми класами: http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.3

Статичний внутрішній клас концептуально не відрізняється від звичайного загального класу, оголошеного у файлі .java.

Оскільки Hibernate повинен створити екземпляр ProjectPK незалежно від екземпляра Project, ProjectPK або повинен бути статичним внутрішнім класом, або оголошений у власному файлі .java.

посилання org.hibernate.InstantiationException: Немає конструктора за замовчуванням