У меня есть API, где представление модели запроса и сущности представлено одним и тем же классом. Упрощенная версия:
class Model {
private Long id;
private Double a;
private Double b;
...
}
Проблема в том, что эти свойства вместе не имеют никакого смысла в качестве объекта запроса. Он вообще не нужен id
, а a
, b
являются исключительными. Код трудно понять без надлежащего разделения. Мой план предусматривает создание отдельных классов запросов: A
и B
для каждого типа ключа.
Меня беспокоит то, что для того, чтобы избежать использования instanceof
(любой код, предполагающий знание всех типов запросов), мне нужно будет реализовать все проблемы перекрестных помех в объектах запроса. Например, сопоставление с WHERE
как часть реального SQL
запроса.
Чтобы избежать того, что клиент имеет неявную зависимость от реализации, моим первоначальным планом является создание классов на стороне сервера, которые расширяют каждый POJO A
и B
и реализуют там детали. Для этого требуется дополнительный слой отображения для отображения из A
в некоторый другой класс, который будет реализовывать sqlQuery()
(упрощая).
Вопрос: Поскольку это кажется достаточно сложным, существует ли какой-то стандартный подход для такого рода проблем? Ссылки, шаблоны приветствуются.
Как вы сказали, реализация отдельных классов запросов кажется хорошей идеей. Стратегия стратегии GOF может быть хорошим моментом для начала, см. Http://en.wikipedia.org/wiki/Strategy_pattern