Существует ли общепринятая практика проектирования объектов, сохраняемых в базах данных?

Question

Существует ли общепринятая практика проектирования Java-объектов, которые часто загружаются и сохраняются в и из баз данных?

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

public interface CalendarSource {
  public Appointment[] getAppointmentsForMonth(int year, int month);
  public void saveAppointment(Appointment appointment);
}

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

Проблема в том, что это простокажется громоздким время от времени.Это сбивает с толку, как обрабатывать значения идентификаторов, так как я действительно не хочу добавлять их в мои объекты.Также требуется одно соединение с базой данных для реализации нескольких различных интерфейсов.По сути, мой пакет базы данных должен полагаться почти на каждый пакет в проекте, потому что он реализует все интерфейсы.Это имеет смысл на определенном уровне, но мне интересно, есть ли лучший способ.

Есть две основные причины, по которым я выбрал эту архитектуру:

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

Одна проблема, с которой я сталкиваюсь, это что делать со значениями ID.Поскольку объекты не должны знать, что они являются объектами базы данных, в них не должно быть поля идентификатора.Но если я пытаюсь записать объект в базу данных, и у меня нет значения идентификатора, как я должен знать, должен ли я делать вставку или обновление?

Я также обеспокоено том, чтобы пакет базы данных расширял все на протяжении всего проекта.Я постоянно передаю эти исходные интерфейсы.Полагаю, это тоже имеет смысл.

Может быть, я просто ищу подтверждение того, что я делаю это правильно, и здесь нет какого-то очевидного простого решения, которого я не вижу.Не поймите меня неправильно - все прекрасно работает.

Есть мысли?

Answer 1

Я думаю, что наиболее универсальным паттерном является паттерн DAO.То есть объект доступа к данным.По сути, вы определяете интерфейс, который определяет поведение (например, базовые операции crud и специализированное поведение для вашего домена), а затем вы предоставляете реализации.Для дополнительных баллов вы можете использовать generics java 5 и выше, чтобы писать меньше кода.

http://www.ibm.com/developerworks/java/library/j-genericdao.html

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

Из вашего поста вы не хотите делать то, что делаете.Используйте Spring или его эквивалент, потому что он будет обрабатывать большую часть кода для вас.Он управляет соединениями, транзакциями и т. Д.

Кроме того, не беспокойтесь о наличии поля идентификатора в ваших классах.Хотя вы можете и не считать это идеальным, это облегчает жизнь.Выбирайте для борьбы большие дизайнерские бои, такие как проведение TDD и поддержание чистоты вашего дизайна.

Answer 2

Ваш подход к «одному центральному объекту базы данных» и «субданным также загружен» кажется направлением к хорошему дизайну.

Однако, поскольку это Java в 2010 году, такие проблемы, как хранение данных и все связанные с ними вещи, уже реализованы.Более того, у вас есть спецификации, такие как JDBC, JPA и JDO, и для этих спецификаций несколько реализаций, таких как Hibernate, Open JPA, EclipseLink ...

Например, JPA и Hibernate - идеальный выбор!Вам потребуется файл конфигурации xml, в котором вы определяете свои конфигурации базы данных (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html).

. Вы можете определить свой постоянный класс Java - отображение таблицы БД в этом xml (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/xml.html) или также с помощью аннотаций (http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/).

Вы будете использовать Hibernate Session / Entity Manager для сохранения своего состояния персистентных объектов в таблицы. (http://docs.jboss.org/hibernate/stable/entitymanager/reference/en/html_single/)

Для значений Id: в большинстве случаев они генерируются, есть несколько возможныхподход к генерации значений. (http://docs.jboss.org/hibernate/core/3.3/reference/en/html/mapping.html#mapping-declaration-id)

Вы можете оставаться независимым от таблиц БД, вы можете реструктурировать, переименовывать в любое время, так как они могут быть перенастроены. Для более сложных изменений вы должны проверить (http://docs.jboss.org/hibernate/stable/core/reference/en/html/inheritance.html)

Если вы перейдете в файловое хранилище, нет проблем, поскольку ваши классы Java являются сериализуемыми классами, вы можете в любое время сохранить их состояние в файле независимо от реализации базы данных. (http://java.sun.com/developer/technicalArticles/Programming/serialization/)

Java World HibernateУчебное пособие

Answer 3

Не катайся сам.

Посмотрите на Hibernate, iBatis и JPA.

Бросай монету. (Мне нравится iBatis, но два других одинаково хороши)

Реализация полностью в выбранной технологии.

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

Внимание! Не бросайте свое.

Answer 4

Я говорю, что самая простая структура, как правило, выглядит примерно так:

Создайте доменные объекты с нужными полями.

Public class Appointment {
private Date appointmentDate;
private String locationName;
List<Person> appointmentAttendees;
}

Затем у вас есть база данных, которая отображает 1 поле в 1 столбец.... и добавьте его в Hibernate для перехода от объекта к объекту базы данных.

Удовлетворит ли это все ваши потребности?Кто знает.Зависит от того, что все, что вам нужно: P