Як реально реалізовані сховища даних Data?

Я працюю зі сховищем Spring Data JPA у своєму проекті вже деякий час, і мені відомо наступні моменти:

• У інтерфейси сховища ми можемо додати такі методи, як findByCustomerNameAndPhone()(припускаючи customerNameта phoneє полями в об’єкті домену).
• Потім Spring забезпечує реалізацію, реалізуючи вищезазначені методи інтерфейсу сховища під час виконання (під час запуску програми).

Мене цікавить, як це було закодовано, і я переглянув джерельний код і API Spring JPA, але не зміг знайти відповіді на наведені нижче запитання:

1. Як створюється і вводиться клас впровадження репозиторію під час виконання та методи?
2. Чи використовує Spring Data JPA використання CGlib або будь-які бібліотеки маніпуляцій з байт-кодом для впровадження методів та динамічно вводити їх?

Чи можете ви допомогти з вищезазначеними запитами, а також надати будь-яку підтримувану документацію?

Перш за все, не відбувається генерація коду, а це означає: немає CGLib, взагалі немає генерації байт-кодів. Фундаментальний підхід полягає в тому, що проксі-екземпляр JDK створюється програмно за допомогою ProxyFactoryAPI Spring для резервного інтерфейсу та MethodInterceptorперехоплює всі виклики до екземпляра та спрямовує метод у відповідні місця:

1. Якщо репозиторій був ініціалізований за допомогою спеціальної частини реалізації (детальніше див. Цю частину довідкової документації ), а метод, що викликається, реалізований у цьому класі, виклик направляється туди.
2. Якщо метод є методом запиту (див. DefaultRepositoryInformationЯк це визначено), механізм виконання специфічного запиту заповнює і виконує запит, визначений для виконання цього методу при запуску. Для цього існує механізм роздільної здатності, який намагається ідентифікувати явно оголошені запити в різних місцях (використовуючи @Queryметод, JPA з іменами запитів), врешті повертаючись до виведення запиту з імені методу. Про механізм виявлення запиту див JpaQueryLookupStrategy. Логіку розбору для виведення запиту можна знайти в PartTree. Переклад конкретного магазину на фактичний запит можна побачити, наприклад, у JpaQueryCreator.
3. Якщо нічого із зазначеного вище не застосовується, виконаний метод повинен бути таким, який реалізований базовим класом сховища для конкретного магазину ( SimpleJpaRepositoryу випадку JPA), і виклик перетворюється на екземпляр цього.

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

Створення цих проксі-серверів інкапсульовано у стандартну реалізацію шаблону на основі Java. Створення проксі-серверів високого рівня можна знайти в RepositoryFactorySupport. Потім для конкретних магазинів реалізації додають необхідні компоненти інфраструктури, щоб у JPA можна було продовжувати та просто писати код так:

EntityManager em = … // obtain an EntityManager
JpaRepositoryFactory factory = new JpaRepositoryFactory(em);
UserRepository repository = factory.getRepository(UserRepository.class);

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

Щоб полегшити інтеграцію з контейнерами DI, ми, звичайно, потім побудували інтеграцію з конфігурацією Spring Java, простором імен XML, а також розширенням CDI , щоб Spring Data можна було використовувати в звичайних сценаріях CDI.