Итак, в основном я проверял работу Hibernate, а также оценивал ORM JOOQ. JPA является основным стандартом де-факто для всех реализаций ORM на основе Java более или менее.
Я не говорю, что они не идеальны и не хороши, но моя проблема в том, что я обнаружил много проблем и ошибок, хотя я использую различные варианты, представленные ниже:
Hibernate:
а. Это теперь API-интерфейс критериев, так что теперь мы должны следовать JPA,
в этом случае я не могу использовать multiselect () или Selection для нескольких столбцов одной таблицы, где у моего боба pojo нет определенного конструктора.
Как например. My Bean / POJO имеют почти 80 столбцов
В одном месте мне нужно всего 10 столбцов, а в другом месте мне нужно 20 столбцов таблицы, в которую отображается мой Бин / POJO.
теперь в таком случае мне нужно создать либо 2 отдельных DTO, содержащих поля выбора, либо мне нужно создать два разных перегруженных конструктора внутри моего основного компонента Bean / POJO.
И это в соответствии с JPA, нет способа, с помощью которого, используя только наборы getter для установки полей, нужно инициализировать мой Bean / POJO.
Идея заключалась в том, чтобы сократить количество классов, которые мы должны создавать без необходимости.
Также, если предположить, что у меня есть такие случаи, когда из таблицы мне нужно выбрать почти 25 различных комбинаций, тогда как в терминах JPA мне нужно создать либо 25 различных конструкторов в одном Bean / POJO, либо 25 различных DTO (WTH).
б. Сбой Hibernate, когда мой конструктор Bean / Pojo похож на
MyBean(String name, String email)
во время выбора, если я сделаю
query.multiselect(new Selection[]{mappingBean.get("email"),mappingBean.get("name")});
Он инициализируется в неправильном порядке, это, по моему мнению, адский недостаток.
(Конечно, разработчик несет ответственность, но все же ошибается)
- Шаблон критерия поиска:
Везде, где нам нужны данные, мы должны писать метод в непосредственной близости, или мы должны писать JPQL, HQL или любой другой сценарий абстракции только для сокрытия SQL
теперь, если у меня в одной таблице 25 разных комбинаций разных скриптов, мне нужно написать 25 разных методов для этих скриптов, поскольку API-интерфейсы критериев, Hibernate или JPS, имеют плохую и сложную систему построения скриптов.
И в случае JOOQ все его java интерпретируются в сценарии. (WTH)
В настоящее время не существует простого API или ORM, которые могли бы удовлетворить требования ниже
Я нашел, Если вы можете помочь мне, я буду очень полон вас.
- Я не хочу использовать HQL JPQL любого языка абстракции вместо SQL, например
Я создал несколько кодов, которые он передавал в качестве объектов методу. Мой API должен это делать.
Если есть случаи объединений (я должен сказать, что не каждая база данных разработана должным образом, особенно в случае внезапных незапланированных изменений), в этом случае мы должны иметь некоторую гибкость для объединений. Каждый раз, когда нет возможности поддерживать правильные отношения (потому что существуют управленческие ограничения, которые ориентированы на доставку, а не на обслуживаемые системы).
Если есть SQL, который я должен написать, я должен писать конкретные части, такие как часть предложения where, или просто части выбора
4.Никто должным образом не поддерживает сложные сценарии, такие как динамические пересечения Unions.
и т. Д. Список весь длинный, но если вы можете помочь мне хотя бы с одним подходящим, вы можете мне помочь ...
Edit:
Теперь редактируем для JOOQ part
Я не исследовал внутренности JOOQ, он также использует AST, но моя проблема с шаблоном, которому он следует, может проверить здесь
если я увижу, что случилось с обычным JDBC, если мне нужно получить мои данные из базы данных в форме Integer или String или отдельного типа данных в виде отдельных полей, это средство, которое мой JDBC дает мне в любом случае там в JDBC позаботьтесь о безопасности типов, я должен сделать это с JOOQ DSL.По крайней мере, я ожидаю, что результат Bean / POJO, как предоставляет Hibernate Criteria API или JPA, отличается тем, что они также имеют свои лаги.
Если у меня есть JOOQ, я не знаю, потому что, как я видел примеры, в его руководствах можно найти коды типов SQL.
Теперь давайте обратимся к другому примеру, который у меня есть (изучив его до сих пор, вы можете помочь мне выяснить некоторые из моих проблем, которые вы можете получить здесь с помощью Hibernate, который я пытался поднять с его сообществом, отметьте здесь и здесь (поскольку вы благодарили и ссылались на API этих тезисов как на источник вдохновения),
Например, примеры JOOQ [! [Пример из JOOQ] [1]] [1]
Теперь, если мы увидим, я должен написать 1 sql или только один набор выборки столбцов, и я в конечном итоге использую это, но представьте, что я должен использовать ту же таблицу с другим набором столбцов в N нет мест, то я должен не пишите ни одного из сценариев (здесь код является взаимозаменяемым JOOQ SCRIPT, проверьте изображение, что я имею в виду, ваш SQL и код выглядят подражающими друг другу) JOOQ DSL,
Итак, я проанализировал это в следующих пунктах:
- Если мне нужно написать N нет различных вариантов выбора, то я либо напишу класс, который обернет все выборки в N нет различных методов, и где бы мне ни понадобилось, мне просто нужно вызывать эти методы на уровне бизнес-логики для получения данные (это то, что я вижу недостатком в HQL, JPQL и JOOQ DSL (согласно рисунку)).
Здесь я буду создавать хаос, создавая N методов, потому что я должен выяснить, о, для 4 столбцов я должен использовать метод X, а для 5 столбцов я должен использовать метод Y, это будет еще хуже, когда у вас есть команда из 100 разработчиков, потому что каждый, возможно, не предпринимает усилий, чтобы найти правильный метод, вместо этого он / она создает там себя, что создаст избыточные и дублирующие коды.
Также я уверен, что вы не хотите называть скрипт как DSL на своем уровне бизнес-логики правильным, потому что вам просто нужно что-то на основе того, почему и в то время как «КАК И ОТ ГДЕ» является задачей ORM и его союзников (здесь Я использую методы DAO и Factory для извлечения данных, используя вызовы DAO в качестве союзников или ORM.
- Теперь еще один способ - у меня будет отдельный набор классов критериев, которые слабо связаны с моими компонентами Bean / POJO, полностью отделенными от ORM. Он будет просто следовать некоторым стандартным правилам ORM, поэтому он может использовать критерии поиска для поиска данных в БД. и верните мне список бобов / POJO.
Так что здесь для любого выбора я просто должен написать один метод, например. мы называем это List findData (SearchCriteria sc) внутри фабричного класса
(M вызывает его как фабрику, потому что он будет иметь метод и объект из DAO, и, используя DAO, он предоставит List Bean, поэтому он станет классом генератора объектов из базы данных, использующей ORM).
теперь этот метод отвечает на основе стандартов за предоставление мне желаемого результата, и в этом случае, где бы на моем бизнес-уровне мне не требовался определенный набор данных, я могу создать критерии поиска и передать его этому методу, который даст мне список Фасоль / POJOs.
Таким образом, я мог бы создать критерии поиска в соответствии с требованием в другой части уровня бизнес-логики, независимо от того, сколько раз N получал данные, но, по крайней мере, я точно знаю, что ответственность за выборку данных лежит только на одном из моих методов. Фабричный класс, который является своего рода разделителем (например, за который вы берете дверь) между моим бизнес-уровнем и моим API-интерфейсом ORM, из заводских вопросов будет обрабатываться ORM, а не пользователем или, я говорю, самим разработчиком.
Надеюсь, вы поняли мою точку зрения.
Эти вещи hibernate или JPA решили немного, но не полностью, потому что их терминология также та же, что везде, где вам нужно использовать построитель критериев, запрос критериев внутри вашего бизнес-уровня, который не является хорошей структурой кода.
Редактировать 2:
Лукас, я получил твоё очко у меня ниже очков
- Проверьте ниже код JOOQ:
public static ResultQuery<Record2<String, String>> actors(
Function<Actor, Condition> where
) {
return ctx.select(ACTOR.FIRST_NAME, ACTOR.LAST_NAME)
.from(ACTOR)
.where(where.apply(ACTOR)));
}
Здесь ACTOR выглядит как фактическое имя таблицы и FIRST_NAME в качестве столбца,так же есть какой-то стандарт, в соответствии с которым мы должны следовать определенной практике кода, или я должен разработать его самостоятельно
, например, A Bean / POJO / DTO, например, UserBean.java может содержать данные, извлеченные из БД, так как это значение по умолчаниюотображение таблицы USER, и мы можем получить данные, используя
ctx.select( *).from(UserBean.class) //I m not sure how do * but will figgure out that separately
Так что в этом случае в идеале должен быть стандартный преобразователь, например, в вышеупомянутом случае UserDAO.java, который будет иметь поля в виде статической конечной строки, содержащейточное имя столбца таблицы и имени таблицы.
это может использоваться фабрикой для вызова на более широком уровне (это просто идея правильной структуры кода),
, так что есть ли практикав списке или шаблон предложения от JOOQ?Я только что дал мои интерпретации.
Что касается пункта 2, я не рассматриваю хорошо спроектированные базы данных, поскольку моя не входит в число тех хорошо установленных схем поддержания отношений и ограничений,
В нем много таблиц, в которых есть общие данные, содержащие столбцы, которые даютправильное отношение между двумя таблицами, но на уровне базы данных не применяется никакого отношения к внешнему ключу.
Теперь в таких случаях в спящем режиме соединение становится слишком сложным, и нам приходится иметь дело с помощью DTO, содержащегокросс-таблицы данных и HQL или простой SQL.
моя идея заключается в том, что если мне нужно объединить две сущности друг с другом, которые не имеют надлежащих отношений на уровне БД, то возможно ли это, и есть ли в JOOQ следующие соглашения?
если есть UserBean и BankAccountBean, где один пользователь может иметь несколько банковских счетов,
, поэтому для сценария ниже
Select A.USER_ID, A.USER_NAME, B.BANK_NAME, B.BANK_ACCT_TYPE, B.BANK_ACCT_NUMBER
FROM USER A LEFT JOIN USER_BANK_ACCOUNT B On A.USER_ID = B.USER_ID
Теперь в этом случае в идеале вместо созданияотдельный новый бин Моя идея в том, что там должен быть UserBankAcctJoinBean должен бытьвозможность обрабатывать выборку данных (здесь необходимо учитывать динамический выбор)
Теперь, если мы говорим о UserBankAcctJoinBean, он должен расширять UserBean (поскольку в моем объединении основная таблица - User), поэтому по умолчанию он наследует всесвойства Users, и он должен содержать ссылочную переменную UserBankAccountBean, поэтому части выбора, принадлежащие USER_BANK_ACCOUNT, должны быть инициализированы по этой ссылке с помощью отражения
Здесь он отличается от Hibernate, поскольку он позволяет иметь объект списка вторичных объектов.таблицы, которая не является основной идеей, потому что в hibernate содержатся правильно установленные отношения между таблицами в схеме.
Есть ли у JOOQ такой или аналогичный способ?
Также, если JOOQ следует шаблону JPA, как он работает внутри в случае динамического выбора, потому что столько, сколько я исследовал JPA в случае динамического выбора, его спецификация говорит, чтобы инициализировать объект напрямую, используя определенный конструктор, и это самая большая проблема, потому что еслиЯ хочу использовать 4-5 разных способов для нескольких разных столбцов, тогда мне нужно использовать 4-5 разных перегруженных конструкторов или создать 4-5 разных Bean / POJO / DTO (этот момент уже был в моих предыдущих изменениях)
Также в случае исходного кода спящего режима он сначала загружает данные из ResultSet в Object [], а затем инициализирует Bean / POJO / DTO, используя методы установки полей, поэтому здесь, если вы видите двойное запаздывание, потому что вместо этогопрямой инициализации объекта с помощью вызова метода установки поля, он сначала сохраняет данные в массив Object, а затем из этого массива загружает их в bean-компонент, который в итоге создает каждую итерацию строки выборки.
Это действительно пустая трата ресурсов, потому что для того жезадачаитерации дважды по одному и тому же набору данных не эффективны,
Так как же JOOQ работает внутри?он напрямую инициализирует данные в DTO с помощью установщиков геттеров или также работает аналогично Hibernate?