Когда вы абстрагируете записи базы данных и наборы данных в объекты, как выглядит ваша объектная модель?

Question

Я прошу всех вас, кто не использует библиотеку для этого, но строит ваши собственные объекты для управления данными, поступающими в ваши таблицы базы данных и из них. У меня есть объект набора записей? один объект на строку данных? И то и другое? Ни? Любые предложения или опыт приветствуются. Пожалуйста, не говорите мне использовать ORM или другой подобный инструментарий. Это излишне для моего проекта, и, кроме того, это уже не вопрос, не так ли?

Answer 1

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

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

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

Кроме того, вам нужно иметь коллекции вещей (база данных - это коллекция коллекций вещей).

Эти "коллекции", "наборы записей", "менеджеры" или "объекты доступа к данным" являются посредниками между постоянством (SQL?) И объектами вашего домена. Набор записей строит ваши доменные объекты из любого материала SQL, к которому у него есть доступ. Аналогично, набор записей раскручивает ваши доменные объекты в SQL-компоненты.

ORM - один из способов справиться с этим; платформа ORM предоставляет эти определения классов. Если ORM «перебор», позаимствуйте шаблоны проектирования. Прочтите API iBatis. [Пока вы занимаетесь этим, вы можете обнаружить, что для ORM нет ничего слишком мелкого.]

Короче говоря, оба: "объект набора записей" плюс "один объект на строку данных" - приблизительно.

Если вы чувствуете необходимость свернуть собственные коллекции наборов записей, вы можете попробовать и использовать простую сериализацию для сохранения ваших объектов. Вы будете иметь сложности, сложенные поверх сложностей, пытающихся сериализовать агрегаты и отношения подкласса. Зачем? Объекты имеют прямые ссылки друг на друга. База данных SQL должна эмулировать это с первичными ключами и внешними ключами.

Answer 2

Я бы настоятельно рекомендовал взять Мартина Фаулера шаблонов архитектуры корпоративных приложений , он описывает ряд шаблонов баз данных, которые было бы полезно знать, и дает вам Идея эволюции шаблонов в полной мере в библиотеках ORM.

конкретные шаблоны, которые могут вас заинтересовать:

• RecordSet
• Шлюз данных строки
• Шлюз табличных данных

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

Answer 3

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

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

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

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

Answer 4

Независимо от размера вашего проекта, я бы сказал, используйте ORM :-P

но .....

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

Обратное применяется для вставки и удаления (с флагом, чтобы указать, что должно было произойти)

Несколько строк обычно помещались в список.

Answer 5

Для управления фактическими данными, поступающими в базу данных и из нее (без ORM), вам следует обратиться к Jakarta Commons DbUtils.

Он предоставляет очень легкие помощники для запуска запросов и обновлений, такие как автоматическое преобразование ResultSets в списки компонентов и т. Д.