2014-10-20 3 views
0

В нашем весеннем проекте у нас есть много контроллеров, которые получают входы (фильтры) для клиентов, это создаст динамические запросы из БД, а набор результатов возвращается обратно клиенту.Общий экспорт в Excel объектов Java

, например:

public List<UserResultDTO> getUsers(Filter filter); 
public List<TransactionResultDTO> getTransactions(Filter filter); 
public List<ProfileResultDTO> getProfile(Filter filter); 

Наш новый requirmemnt очень просто: «Пожалуйста, позвольте экспорт из этих списков результатов к Excel файл»

Вся идея экспорта в файл Эксел уже позаботились. (У нас очень надежный поставщик Excel)

Таким образом, наша цель состоит в том, чтобы создать очень универсальную функцию \ службу, которая примет список и сможет экспортировать его общим способом.

Любые идеи, что лучше всего подходит для такого рода задач?

идея в виде:

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

2) Использование отражения может быть? Возможно даже использование аннотаций для полей для названий столбцов Excel

3) Другое?

Спасибо!

ответ

1

Наверняка нет переименования; что добавит искусственную взаимозависимость: если некоторые независимые DTO изменены, перечисление посещается пару раз.

Существует BeanInfo API, метаинформация, хранящаяся как Java-класс, параллельный классу DTO. Это особенно важно для такого рода ситуаций. Но возможно overkill.

Таким образом, это, вероятно, сводится к собственному адаптеру, давая разумный выход с использованием отражения. И автоопределение улучшения использования декларативных средств:

  • (не так хорошо) аннотаций в DTOS (как развиваются DTOS?)
  • XML или .properties с полным именем класса; один XML в классе
+0

Спасибо за ответ Joop! У нас небольшой проект, и похоже, что BeanInfo API - это именно то, что вы сказали: overkill. можете ли вы подробнее рассказать об альтернативе? Кстати, DTO разрабатываются командой сервера (наша команда, 5 разработчиков). – Urbanleg

+0

Я думаю, что имена столбцов и их формирование являются единственными точками. Если вы считаете интернационализацию, то свойства .properties были бы точны для сопоставления из имени переменной/имени SQL для локализованного имени столбца. –