#java #data-access-layer
#java #уровень доступа к данным
Вопрос:
У меня есть метод в моем уровне доступа к данным, который обрабатывает импорт файла. В таком файле может быть много записей, которые необходимо вставить в базу данных. Этот метод уже содержит определенные «логические или бизнес-правила», и необходимо добавить больше. Проблема в том, что если я перемещу это из уровня доступа к данным, каждую запись придется вставлять отдельно с новым подключением. Очевидно, что это не очень хорошо при вставке тысяч записей. (нет гарантии, что соединения объединены в пул). Так что я немного запутался в том, как это решить. Класс уровня доступа к данным становится все больше и больше, и с точки зрения хорошего дизайна ОС, вероятно, уже нарушает несколько правил.
Единственное, что приходит мне в голову, это файл импорта producer-consumer -> business logic, который выполняет проверку и помещает проверенные записи в очередь. Отдельный поток (уровень доступа к данным) считывает данные из этой очереди.
Есть другие идеи? существует ли шаблон для таких проблем?
Ответ №1:
У вас проблема с дизайном. Уровень бизнес-логики должен быть тем, который разграничивает транзакции, а уровень доступа к данным всегда должен использовать одно и то же соединение для данной транзакции.
Например, вы могли бы использовать Spring, что позволило бы вам использовать декларативные транзакции и пул соединений и убедиться, что одно и то же соединение используется для всей транзакции.
Комментарии:
1. Таким образом, бизнес-уровень может содержать код JDBC с вводом, нарушающим определенные принципы? Это довольно простая и простая вещь, поэтому я хочу избегать «больших корпоративных библиотек».
2. Нет. Бизнес-уровень должен запустить транзакцию (декларативно), вызвать уровень доступа к данным для получения / хранения / поиска бизнес-объектов и реализовать бизнес-логику для этих бизнес-объектов. Каждое взаимодействие с базой данных должно выполняться в DAL. Использование spring transaction manager и вспомогательных классов spring jdbc не так сложно / предприимчиво, как вы могли подумать.
Ответ №2:
- Создайте отдельный бизнес-уровень, отдельный от уровня доступа к данным — здесь разберитесь с вашими бизнес-правилами, и когда вы будете готовы обратиться к доступу к данным, создайте коллекцию бизнес-объектов — затем перейдите на уровень DA — уровень DA будет обрабатывать объекты — либо как отдельные строки, либо как одну массовую операцию —
- Используйте шаблоны проектирования на вашем бизнес-уровне, которые упростят эволюцию.
Комментарии:
1. Невозможно передать все объекты сразу на уровень DA из-за потребления памяти. Объект имеет сверхтяжелый вес. хотя в большинстве случаев все будет в порядке, в некоторых это не так, и, следовательно, я должен быть готов к этому случаю.
2. Не уверен, что я понимаю, что вы подразумеваете под «Не могу пройти .. потому что объекты тяжелые» — Передача объектов на другой уровень не зависит от того, насколько тяжелы объекты — вы передаете ссылки, а не создаете их клоны.
3. Я имею в виду, что если у меня большой объем данных, я не могу хранить все это в памяти. Если, например, входные данные представляют собой файл, мне пришлось бы обрабатывать каждую запись (или набор записей) по отдельности и передавать их на уровень DA для сохранения. Конечно, тогда я не смогу выполнить весь процесс в одной транзакции, по крайней мере, с простым JDBC.