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

Question

У меня есть вопрос относительно того, как использовать объектно-ориентированный подход при использовании СУБД, такой как mysql. Я разрабатываю небольшое приложение, которое будет следить за выставлением счетов. Он построен на Java, и я использую базу данных MySQL для хранения данных. В моем приложении есть клиент и класс продукта. Теперь обычно, если бы я имел дело с постоянным хранением данных с использованием массивов или других контейнеров данных, у меня было бы обновление, удаление и т. Д. Для класса клиента и одного для класса продукта. Однако я обнаружил, что использую больше статических методов, чем когда-либо прежде. Поскольку у меня нет массива клиентов, например, у меня просто есть база данных с информацией о клиентах, я не вижу смысла в создании объекта клиента, чтобы просто удалить его, когда я мог бы просто вызвать статический метод, который удаляет клиент (или продукт) на основе на его основной идентификатор. В конце концов, я чувствую, что нет никакой причины даже создавать класс клиента или продукта, потому что нет необходимости в конкретных методах.

Я хотел бы спросить всех, как вы подходите к объектно-ориентированному подходу при использовании СУБД?

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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