Задача
У меня есть код, который превращает данные, хранящиеся в реляционной форме, в модель предметной области. Источником является не СУБД, а набор сгенерированных «табличных» классов. Эти классы таблиц сопоставимы с java.sql.ResultSet
, каждый из которых представляет один набор данных: заказы, заказанные товары, поставки, счета, серийные номера.
Код преобразования создает иерархию моделей предметной области с нуля путем итерации по таблицам. Он создает соответствующие объекты модели, подключая их к другим объектам модели и так далее. По окончании возвращает модель домена (список заказов).
Проблема заключается в том, что код преобразования объединен в один класс и охватывает различные аспекты данных, поэтому очень сложно выполнить модульное тестирование, найти ошибки или расширить его. Мне нужно хранить этот код годами, и я действительно хочу как-то его разделить, но я не уверен, какой шаблон проектирования может здесь подойти.
Идея
Я склоняюсь к рефакторингу кода в шаблон посетителя:
- вводит контейнерный класс, который предоставляет ссылки на объекты таблицы (например,
getOrdersTable()
, getOrderItemsTable()
)
- создать несколько классов посетителей для этого класса контейнера. Каждый посетитель охватывает один аспект исходных данных: один, который создает сами объекты заказа, другой создает объекты доставки и подключает их к соответствующим объектам заказа и т. Д.
Однако я не уверен в следующих проблемах :
- посетители будут работать не только с объектами таблицы, которые они посещают, но и с объектами, созданными другими посетителями (где последние доступны через список заказов, который является корнем модели домена). Таким образом, порядок, в котором вызываются посетители, важен.
- Шаблон посетителя часто объясняется в контексте иерархий узлов, но я не хотел бы, чтобы они посещали иерархию, они создавали бы один.
Вопросы
Является ли Visitor хорошим выбором или вы выбрали бы другой известный шаблон? Или это тот случай, когда ни один шаблон проектирования не применяется действительно хорошо, и я должен избегать (не использовать) терминологию шаблона?
Является ли какая-либо из проблем выше необычной для посетителей? Если да, то как вы думаете, реализация Visitor в любом случае может привести к путанице в коде? В конце концов, шаблоны - это соответствие интуитивным ожиданиям и повышение значимости кода.
Контекстная информация
- Я могу безопасно добавлять методы в классы таблиц (каждый из которых состоит из сгенерированного абстрактного класса и подкласса, предназначенного для ручной модификации), или же они могут реализовывать интерфейсы, но не могут изменять свой общий суперкласс или вводить новый.
- Набор таблиц относительно стабилен, но, вероятно, будут добавлены новые столбцы. Кроме того, есть некоторая степень изменения в самой логике преобразования (например, какие команды пропустить, или в особых случаях для отображения данных)
- Сама модель предметной области относительно чистая, я не собираюсь менять ее несовместимыми способами или даже полностью ее заменять.
- Речь идет о коде Java.
- Безопасность резьбы не требуется.