Я в анти-шаблоне, и я хочу выйти
Я разрабатываю java webapp, используя jsp/jquery/ejb/jboss.
У меня есть веб-форма, которая позволяет пользователю выбирать любую комбинацию из 100 полей (все из разных несвязанных таблиц/объектов) из базы данных. Затем эти поля выводятся через сервлет java в таблицу Excel. Выполняется хранимая процедура, которая всегда возвращает все 100 полей.
Веб-форма устанавливает 100 булевых значений в объекте передачи (TO), чтобы определить, должны ли отображаться данные. Затем этот TO ссылается на создание строки заголовка электронной таблицы, а также для каждой строки из базы данных, которая переименована.
Все работает отлично, однако это неправильно. Я не могу думать о жизнеспособном способе, который не ссылается на 100 булевых (N + 1 раз), чтобы определить, должно ли поле быть включено в выводимую электронную таблицу. Когда я говорю о жизнеспособности, я имею в виду, например, что я не хочу переписывать хранимую процедуру или создавать 100 различных хранимых процедур.
Ответы
Ответ 1
Наше решение было в аналогичных ситуациях для создания динамического Transfer Object. В принципе, это был Map
вместо POJO, имеющего несколько геттеров и сеттеров.
Коды, заполняющие и считывающие этот объект передачи, были простыми итерациями.
Ответ 2
Вместо того, чтобы использовать хранимую процедуру для этого, вы не могли бы динамически строить строку выбора SQL в своем приложении, а затем выполнять эту инструкцию SQL. Поэтому вам нужно всего лишь ссылаться на booleans один раз, и вы возвращаете только нужные столбцы.
Ответ 3
Вы можете исключить перечисление поля вручную:
-
при загрузке формы, для каждого из доступных полей электронных таблиц вы выводите логический элемент управления. Вероятно, лучше всего добавить префикс, чтобы у вас не было конфликтов с любыми другими полями, которые существуют в форме.
-
при отправке формы вы показываете любые включенные поля, у которых есть префикс.
Ответ 4
Вам нужно будет оценить, действительно ли это лучше, но вы можете использовать подход, в котором вы используете бит-массив для хранения того, будут ли использоваться поля. Каждое поле будет иметь значение, соответствующее одному биту:
static final FIELD1 = 1;
static final FIELD2 = 2;
static final FIELD3 = 4;
static final FIELD4 = 8;
static final FIELD5 = 16;
etc
Каждое поле формы будет иметь значение своего битового значения при выборе или 0, если оно не выбрано. При отправке формы суммируйте поля и отправьте их. Поэтому, если поля FIELD1 и FIELD3 были отмечены, вы должны указать значение 5 (00101 в двоичном формате).
Затем вы применяете простую битовую маску для каждого поля, чтобы определить, какие из них были выбраны (есть ли лучший способ, чем поле за полем?):
boolean field1Selected = sum & FIELD1;
boolean field2Selected = sum & FIELD2;
etc
Недостатки: со 100 полями вы говорите о действительно большом количестве! Возможно, вам придется использовать 2-битные массивы. Я также не уверен, что это действительно упрощает вашу проблему, но может быть и так.