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

Question

У меня есть метод в моем слое доступа к данным, который обрабатывает импорт файла.В таком файле может быть много записей, которые необходимо вставить в базу данных.Этот метод уже содержит определенные «логические или бизнес-правила», и его необходимо добавить еще.Проблема в том, что если я переместу это из уровня доступа к данным, каждая запись должна быть вставлена ​​отдельно с новым соединением.Очевидно, что это не очень хорошо при вставке тысяч записей.(нет гарантии, что соединения объединены).Так что я отчасти заблудился, как решить эту проблему.Уровень слоя доступа к данным становится все больше и больше, и с точки зрения хорошего дизайна, возможно, он уже нарушает несколько правил.

Единственное, что мне приходит в голову, это файл производитель-потребитель -> бизнес-логика импортирует файл, выполняет проверку и помещаетпроверенные записи в очередь.Отдельный поток (уровень доступа к данным) читает из этой очереди.

Есть еще идеи?Есть ли шаблон для таких проблем?

Answer 1

У вас проблема с дизайном. Уровень бизнес-логики должен быть той, которая разграничивает транзакции, а уровень доступа к данным должен всегда использовать одно и то же соединение для данной транзакции.

Например, вы могли бы использовать Spring, который позволил бы вам использовать декларативные транзакции и пул соединений, и обеспечил бы одно и то же соединение для всей транзакции.

Answer 2

1. Наличие отдельного бизнес-уровня, отдельного от уровня доступа к данным - здесь рассматриваются ваши бизнес-правила, а когда вы готовы обратиться к доступу к данным, создайте коллекцию бизнес-объектов - затем перейдите на уровень DA - DAслой будет обрабатывать объекты - как отдельные строки или как единая массовая операция -
2. Использование шаблонов проектирования на бизнес-уровне, что облегчит эволюцию.