Как вы решаете эти распространенные проблемы БЕЗ использования ORM и использования прямого JDBC (или эквивалентного)?

Question

Когда я использую только JDBC, мне обычно приходится думать о следующих проблемах. Я не слишком много думаю и просто заставляю что-то работать, но мне интересно, как люди справляются с этим без ORM или другой библиотеки.

1. Стремление против ленивых Загрузка: У вас есть только один объект домена, и зависимые дочерние элементы имеют нулевое значение, и вызывающий абонент обязан вызывать DAO для загрузки этих дочерних элементов при необходимости? Или вы просто используете несколько объектов передачи для одного объекта домена? Это также означает, что вам придется поддерживать отдельные запросы SQL для нетерпеливого и ленивого случая.

2. Доменные объекты и объекты передачи: Вам даже нужны как доменные объекты, так и объекты переноса? В приведенном выше случае может быть проще выполнить это с помощью различных представлений объектов домена через объекты передачи. Наконец, при использовании объектов переноса связанные объекты будут «отделены»? Другими словами, если у вас есть родительский класс с несколькими дочерними объектами, будет ли родительский объект иметь экземпляр коллекции дочерних элементов или они будут запрошены отдельно?

3. Назначение идентификаторов: На данный момент я сделал пакет в транзакции, а затем назначил идентификаторы в конце. Однако для этого требуется публичная функция для установки идентификатора ...

4. каскадный: Я думаю, что единственный выбор - сделать это вручную ...

Есть еще, но это все, что я могу думать сейчас.

EDIT: Что касается того, почему я задаю этот вопрос, вы знаете, как некоторые команды разработчиков «боятся» использовать ORM или не любят их по какой-либо причине (обычно потому, что они их не понимают), поэтому иногда JDBC - ваш единственный выбор .

Answer 1

Итак, суть в том, что есть различные решения для каждой проблемы, и правильное решение будет зависеть от контекста: не существует единого подхода, подходящего для всех.

Например, для номера три у нас есть таблица, в которой поддерживается уникальный счетчик идентификаторов для каждого типа (одна строка для каждого типа сущности): когда вы хотите указать идентификатор, выберите текущее значение для типа, а затем увеличьте его в базе данных. Это простое решение, но оно не так хорошо масштабируется: если вы хотите улучшить его, вы можете сделать так, чтобы прикладной уровень массово распределял нагрузку по этим идентификаторам (скажем, 50 для каждого типа), а затем раздавал их по мере необходимости, когда вставка новых данных, возвращение в БД только после исчерпания пула. По сути, это эмуляция чего-то вроде последовательности Oracle .

Для номера четыре каждый класс сущности (классы, которые обертывают одну таблицу), который связан с другим типом сущности, отвечает за каскадное удаление и т. Д.

В конце концов, ORM - это просто абстракция, так что, если вы загляните внутрь, все эти проблемы были решены разработчиками библиотеки. В этом случае вам просто нужно сделать работу!