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

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

но.....

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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