Главная » Spring » Работа с базами данных Spring

0

После знакомства с контейнером Spring пришло время приме- нить полученные знания для создания действующего приложения. Лучше всего начать с требования, которое предъявляется к любому корпоративному приложению, такого как возможность хранения данных. Каждый из нас, вероятно, уже имел дело с базами данных в прошлом. При этом вы знаете, что доступ к данным имеет много препятствий. Нужно настроить фреймворк для доступа к данным, открыть соединения, обработать различные исключения и закрыть соединения. Если в этой последовательности что-то будет сделано неправильно, можно испортить или удалить важные данные. Если вам не приходилось испытывать последствия ошибок при обраще- нии с данными, то поверьте на слово, это весьма неприятно.

Так как мы стремимся избежать неприятностей, обратимся за по- мощью к фреймворку Spring. В Spring имеется набор модулей для интеграции с различными технологиями хранения данных. Если для хранения данных используется непосредственно JDBC, iBATIS или фреймворк объектно-реляционного отображения (ORM), такой как Hibernate, Spring избавит вас от рутины при разработке программ- ного кода, реализующего доступ к данным. Вместо возни с низко- уровневым доступом к данным можно положиться на Spring, кото- рый выполнит эту работу за вас, и сконцентрироваться на управле- нии данными в самом приложении.

В этой главе мы приступим к созданию Twitter-подобного при- ложения под названием Spitter. Это приложение станет основным примером для остальной части книги. Первое требование, которое мы постараемся удовлетворить, – реализовать слой, обеспечиваю- щий хранение данных приложения Spitter.

Приступая к разработке этого слоя, мы сразу же сталкиваемся с необходимостью выбора. Для доступа к базам данных мы могли бы использовать JDBC, Hibernate, Java Persistence API (JPA) или любой другой подобный фреймворк. К счастью, Spring поддержи- вает все эти механизмы хранения данных, поэтому мы попробуем использовать каждый из них.

Но сначала заложим некоторые основы и познакомимся с фило- софией хранения данных в Spring.

Философия доступа к данным в Spring

В предыдущих главах говорилось, что одна из целей Spring – обеспечить возможность разработки приложений, основанных на интерфейсах, в соответствии с принципами объектно-ориентиро- ванного программирования (ООП). Поддержка доступа к данным в Spring не является исключением.

Аббревиатура DAO1 обозначает «объект доступа к данным» (Data Access Object), что прекрасно описывает роль DAO в приложении. Объекты доступа к данным являются средствами чтения и записи данных в базу данных. Они должны предоставлять эту функцио- нальность через интерфейс, доступный остальной части приложе- ния. Рисунок 6.1 демонстрирует правильный подход к проектиро- ванию слоя доступа к данным.

Как показано на рисунке, прикладные объекты получают доступ к DAO через интерфейсы. Такая организация дает несколько пре- имуществ. Во-первых, это упрощает тестирование прикладных объ- ектов, так как они не связаны с конкретной реализацией доступа к данным. На самом деле можно создать фиктивные реализации этих интерфейсов доступа к данным, позволяющие проверять приклад- ные объекты без необходимости подключения к базе данных, что значительно ускоряет процесс тестирования и исключает вероят- ность ошибок из-за противоречивости данных.

1 Многие разработчики, включая Мартина Фаулера (Martin Fowler), на- зывают объекты доступа к данным репозиториями. Я высоко ценю рас- суждения, которые ведут к использованию термина «репозиторий», но полагаю, что слово «репозиторий» имеет слишком широкое толкование и без этого дополнительного значения. Поэтому приношу свои извинения, но я не буду следовать этой популярной тенденции и продолжу называть эти объекты объектами доступа к данным (DAO).

Рис. 6.1. Прикладные объекты не реализуют доступа к данным.

Вместо этого они делегируют эти операции объектам доступа к данным. Интерфейс объектов DAO обеспечивает

слабую связанность с прикладными объектами

Кроме того, слой доступа к данным обеспечивает независимость от конкретной реализации хранилища. То есть подход на основе ис- пользования DAO обеспечивает «изоляцию» выбранного хранили- ща, предоставляя только ключевые методы доступа к данным через интерфейс. Это повышает гибкость архитектуры приложения и по- зволяет заменить используемый фреймворк на другой с минималь- ными воздействием на остальной программный код. Если детали реализации уровня доступа к данным будут просачиваться в другие части приложения, то все приложение окажется тесно связанным с уровнем доступа к данным, что сделает конструкцию приложения более жесткой.

Примечание. Если после прочтения двух предыдущих абзацев вы чув- ствуете, что я делаю сильный уклон в сторону сокрытия слоя хранения данных за интерфейсами, то я рад, что смог донести до вас эту точ- ку зрения. Я считаю, что интерфейсы являются ключом к написанию слабосвязанного кода и что они должны быть использованы во всех слоях приложения, а не только на уровне доступа к данным. Важно также отметить, что хотя фреймворк Spring поощряет использование интерфейсов, он не требует этого – вы можете использовать Spring для внедрения компонентов (объектов DAO или других) непосредственно в свойства других компонентов, не прибегая к использованию интер- фейсов.

Один из способов, какими Spring может помочь оградить уро- вень доступа к данным от остальной части приложения, заключается в предоставлении последовательной иерархии исключений, исполь- зуемых во всех модулях DAO.

Источник:   Уоллс К., Spring в действии. – М.: ДМК Пресс, 2013. – 752 с.: ил.

По теме:

  • Комментарии