Объектно-ориентированный подход с использованием РСУБД

Создавайте свои классы Java, используя принципы объектно-ориентированного программирования.

Создайте свою БД с помощью SQL и принципов нормализации.

Затем на полной скорости примите вызов, который представляет собой объектно-реляционное картирование! :-)

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

Абстрагируйте свое постоянство на уровень DAO (объект доступа к данным), например. если у вас есть много классов, таких как Vehicle и Animal, у вас будут DAO, такие как VehicleDao и AnimalDao, чтобы отделить то, как они общаются с БД, от того, что они в основном делают в вашей системе.

FWIW, я рекомендую делать именно это: хороший дизайн приложения на стороне приложения, хороший дизайн БД на стороне данных. Сделав это, всегда есть способ сопоставить их при сохранении и извлечении данных класса в БД и из нее, и это гораздо лучше IMO, чем скомпрометировать один из ваших отдельных слоев, чтобы «помочь» другому.

Использование DTO (объектов передачи данных), которые в вашем случае будут классами, представляющими объекты в базе данных, соответствует принципу единой ответственности. Это шаблон проектирования, основанный на принципах ООП (точнее, на процессе инкапсуляции). Это гарантирует, что каждый из ваших классов выполняет только одну цель. Если вы храните свою бизнес-логику внутри строк SQL, ее становится трудно поддерживать, и это нарушает принцип DRY «Не повторяйтесь». По моему опыту, ORM ускорили процесс проектирования системы. Попробуйте NHibernate. http://geekswithblogs.net/pariam/archive/2006/07/26/86352.aspx

Если вы ожидаете, что это приложение когда-либо будет расти (что, вероятно, составляет 99% приложений), создайте объекты. Даже если удаление представляет собой один вызов SQL, в будущем вам может понадобиться добавить логику (удалить строки в дочерних таблицах, сохранить данные аудита, перейти к логическому удалению вместо окончательного удаления и т. д.).

Ваша база данных представляет ваши бизнес-объекты - полностью нормализована и т. д.

Ваша объектная модель представляет, как вам нужно работать с данными в вашем коде. Обычно они не совпадают, например, у вас есть таблица клиентов, связанная один ко многим с таблицей адресов, но в коде вы используете объект, который содержит оба типа информации.

Ваши объекты доступа к данным (DAO) обрабатывают бизнес-объекты (т. е. чтение/запись). Ваш сервисный уровень выполняет свою работу, объединяя выходные данные DAO в ваши объекты, если это необходимо. Ваш сервисный уровень также будет обрабатывать транзакции по мере необходимости.

Абстрагирование вашего доступа к данным от вашего сервисного уровня упростит поддержку кода, обновление схемы базы данных и упростит тестирование.

Работа с базами данных и oo-кодом всегда была горячей темой. Некоторые могут сказать: "ПРОСТО НЕ ДЕЛАЙТЕ".

Я не согласен с этим, но я видел много проблем, когда мне приходилось это делать. Я абсолютно не согласен с некоторыми другими, которые сразу же рекомендуют OR-Mappers, такие как Hibernate. Во многих случаях вы не получаете никаких преимуществ во время разработки и получаете много проблем (производительность, диагностика ошибок) во время выполнения.

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

Но если вы действительно имеете дело с клиентами внутри приложения, будет полезно установить объект клиента, а затем вам нужно ИЛИ-сопоставление. Но вам не нужна структура. Рукописный sql/JDBC отлично справляется со своей задачей в большинстве случаев.

С моей точки зрения, OR-Mapper-Frameworks может быть хорошей вещью в приложениях, где производительность неинтересна, и вы не в настроении думать обо всех этих вещах БД (т.е. прототипировании) в большинстве других случаев я бы пошел с рукописным кодом для чтения и хранения.

Модель домена — хороший подход. Разделите свою бизнес-логику на слой, который не зависит напрямую от базы данных. Используйте принципы SOLID и посмотрите на проект, ориентированный на предметную область. Таким образом, у вас будет читаемый объектно-ориентированный код, который изолирован и может быть легко протестирован. Такие шаблоны, как «Репозиторий», помогут вам сосредоточиться на бизнес-требованиях, работая с реалиями реляционной базы данных. По сути, вы определяете и интерфейс, например:

List<Customer> customers = Customers.WithOutstandingOrders(DateRange range)

А затем реализовать этот интерфейс на уровне доступа к данным (за пределами вашего домена). Самый простой способ — использовать ORM, например Hibernate. Роль базы данных в этой архитектуре больше похожа на «битовое ведро». Другими словами, большая часть логики находится в объектно-ориентированном коде, а база данных просто защищает от аномалий данных и ускоряет работу (используя нормализацию, ссылочную целостность и индексы).