вторник, 21 января 2014 г.

А давайте перепишем DAO с использованием возможностей Java 8

В последние годы складывается следующая тенденция развития объектно-ориентированных языков программирования: к ним добавляют все больше и больше элементов, взятых из мира функционального программирования. C# обзавелся поддержкой анонимных функций несколько лет назад, настала пора и Java-разработчикам приобщиться к прекрасному. Поддержка анонимных функций и основанный на их широком использовании новый API Collection Framework'а ждет нас в Java 8. Интернет уже запестрил статьями вида "Как написать свой Hello World на Java 8". Но писать Hello World не интересно, давайте лучше рассмотрим, как можно использовать новые возможности для решения конкретных задач в нашем суровом "Ынтырпрайз" мире.

вторник, 14 января 2014 г.

DAO на голом JDBC без использования Spring Framework и AOP. Хотите немного функциональной магии?

Здравствуйте, уважаемые подписчики. Праздники кончились и очень хочется немного поработать. Сейчас Суровый разрабатывает небольшое интеграционное решение, оперирующее коллекциями разнообразных объектов. Так как есть весьма критичные требования к производительности, а ассоциации между объектами практически отсутствуют, то было принято решение отказаться от использования ORM и ограничиться чистым JDBC. А так как мы работаем с коллекциями, то всегда найдется место для функциональной магии. В данной статье я расскажу об организации "коллекционно-ориентированного" слоя доступа к данным.

Используем паттерн QueryObject


В интеграционном проекте приходится решать две основные задачи: извлекать коллекции объектов из одного хранилища, например базы данных, и записывать их в другое. Соответственно, концептуально мы имеем две операции: load и save. При этом типов объектов и алгоритмов их загрузки/извлечения может быть очень много. Для организации DAO можно описать все операции в виде методов в одном классе. Получится класс, состоящий из N*2 методов, где N - количество типов объектов. Данный класс будет очень большим и сложным, по сути у нас получится просто некоторое кладбище SQL-запросов, которое будет чрезвычайно трудоемко как сопровождать, так и тестировать.

Можно разделить передаваемые типы данных на группы по функциональному признаку и создать не один класс DAO, а несколько. Однако опыт подсказывает, что при интеграции как правило выделяется одна функциональная область, число типов данных в которой значительно превышает все остальные. Речь идет о нормативно-справочной информации (НСИ). Создание нескольких классов по два-три метода и одного с двадцатью методами не является решением проблемы. Антипаттерн "волшебный объект" все еще остается в системе.

Пойдем другим путем. Воспользуемся паттерном QueryObject. При использовании данного паттерна мы инкапсулируем логику загрузки каждого типа объекта в свой класс. Аналогично поступаем с логикой сохранения данных. Таким образом у нас получается N*2 маленьких классов, состоящих из одного бизнес-метода. Данные классы легко сопровождать и тестировать. В случае необходимости очень просто сделать заглушку (mock) - необходимо подменить всего один метод. Вероятность конфликтов при работе с системой контроля версий так же уменьшается.