Можно ли иметь одноэлементные объекты DAO?

Question

Рассмотрим структуру следующих классов:

1. BaseDAO с методами для гребни PreparedStatement и получения соединения из пула
2. AccountDAO extends BaseDAO для работы с таблицей Account через JDBC,Этот класс - singleton
3. AccountService, который вызывает методы AccountDAO следующим образом: AccountDAO.getInstance().login(name, password).

AccountDAO - это бин Spring с аннотациями @Transactional для методов, которые вставляют некоторыеданные.

Это нормально?Я думаю, что одиночные классы DAO могут вызвать проблемы с производительностью.Может быть, лучше использовать некоторые весенние инъекции в классы слоя обслуживания?(Я новичок в весне, поэтому любые советы будут оценены)

Answer 1

Рекомендуемый подход в документации Spring заключается в написании ваших DAO как обычных классов и использовании одноэлементной области видимости. Это будет работать нормально, если ваши DAO не поддерживают состояние.

http://static.springsource.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-prototype

раздел 3.4.2.

Если вы используете Spring, вам не нужно иметь дело с подготовленными утверждениями и еще чем-то, если только вы не делаете что-то непонятное. Посмотрите на JdbcTemplate или HibnerateTemplate. Да, вам следует подключить Spring для внедрения ваших DAO в ваши сервисы или везде, где вам нужно их использовать.

Answer 2

Я не слишком знаком с Spring, но в целом вы не хотите, чтобы соединения с вашими источниками данных были доступны из нескольких потоков. Это, вероятно, О.К. если вы настроите его так, чтобы объекты DAO были псевдосинглетами в контексте потока, но не были общими для потоков. Большинство контейнеров IoC позволят вам сделать это через конфигурацию.

Конечно, это приводит к другим соображениям относительно согласованности данных, и вы должны тщательно ими управлять. Как правило, часть ORM поможет вам в этом.