Лучшая практика для обработки пустых строк из базы данных (в Java)
В моем приложении базы данных мне иногда приходится иметь дело со строками null в базе данных. В большинстве случаев это нормально, но когда дело доходит до отображения данных в форме, компоненты Swing - например, с использованием JTextField - не могут обрабатывать пустые строки. (.setText(null) не работает)
(Обновлено: Я только что заметил, что JTextField фактически принимает строку null, но вопрос остается для всех других случаев, когда неожиданные значения null могут привести к проблемам.)
Нулевые значения не имеют особого значения, они могут (должны) рассматриваться как пустые строки.
Как лучше всего решить эту проблему? К сожалению, я не могу изменить базу данных.
- Проверять каждое значение, если это
null, перед вызовомsetText()? - Добавлять обработчик try-catch к каждому вызову
setText()? - Представляете статический метод, который фильтрует все строки
null? - Заменить все значения
nullна пустые строки сразу после чтения из базы данных? - ... [ваши предложения]
Ответы 7
Если можете, добавьте значение по умолчанию - пустую строку - для поля в БД.
Если вы используете какой-либо инструмент ORM или каким-то образом сопоставляете поля своей БД с Java-компонентом, вы всегда можете иметь:
public void setFoo(String str) {
this.foo = str != null ? str : "";
}
Вы должны быть осторожны при обратной записи данных в БД, так как вы будете вставлять пустую строку вместо значения NULL!
Думаю, это лучшее решение, но я изменю геттер. (Я думаю, это то, что вы имели в виду все время)
Я думаю, что Марком установил сеттер, поскольку он используется большинством инструментов ORM, например. hibernate, чтобы поместить значения из базы данных в экземпляры. При использовании геттера вам все равно нужно быть осторожным, чтобы избежать побочных эффектов в базе данных при использовании инструмента ORM.
FWIW, я бы перевел неравенство на проверку на равенство. Еще одна передовая практика (или мнение, в зависимости от того, как вы на это смотрите). public void setFoo (String str) {this.foo = str == null? "": str; }
В Oracle я не считаю, что это проблема. Это может зависеть от настроек, но наша реализация 10g интерпретирует пустые строки как пустые. Другие СУБД и, возможно, другие конфигурации могут отличаться.
Тогда как вы можете проверить, является ли значение пустым в БД или NULL из вашего объекта Entity?
С точки зрения SQL попробуйте:
select ISNULL(column_name,'') from ...
Кто-то только что пометил этот ответ :(. Хотя я согласен с тем, что вопрос касается Java. Это решение можно использовать для обработки ВСЕХ неожиданных нулевых значений из базы данных. И, как говорится в вопросе, «к сожалению, я не могу изменить базу данных», это подразумевает, что ответы, отличные от java, также приемлемы.
Вы можете расширить или обернуть JTextField и перезаписать метод setText (), чтобы заменить NULL пустой строкой.
Да, но на самом деле "NULL" может быть допустимым значением в БД;>
В самом деле, именно поэтому вы должны обернуть setText () и getText (), чтобы вы могли заменить null на "" для setText и наоборот для getText.
Как сказал Рубен, я бы расширил JTextField, чтобы перезаписать метод setText () и заменить NULL пустой строкой.
Однако я бы также перезаписал метод getText (), чтобы перезаписать пустую строку с помощью NULL, чтобы при сохранении обратно в базу данных вы не перезаписывали там нулевое значение пустой строкой.
Используйте Beans Binding API для привязки значений из ваших объектов сущности к вашим виджетам SWING. Beanins Binding будет прозрачно обрабатывать нулевые значения и не заменяет нуль пустой строкой.
Я думаю, что все ваши ответы разумны, но, поскольку вы отметили этот «передовой опыт», я хотел бы напомнить вам о шаблоне проектирования нулевого объекта. Везде, где это кажется стоящим усилий, для любого класса, нуждающегося в защите, напишите специальный код создания экземпляра для «нулевого» объекта этого класса. Идея в том, что этот «нулевой» объект реален и может вести себя соответствующим образом, независимо от того, что вы его просите. Ваш нулевой объект "String" может предоставить все, что вы хотите, в качестве его значения.
Этот шаблон также означает, что вы можете избавиться от множества нулевых проверок и сделать код более надежным. Он использует немного ЦП, отправляя сообщения нулевым значениям и не заставляя их ничего делать, поэтому это менее желательно, когда ожидается, что большой процент объектов будет нулевым.
Да, это было бы лучше, но, к сожалению, я не могу этого сделать :(