Java: это хорошая практика для определения bean-компонентов в XML? - PullRequest
5 голосов
/ 25 января 2011

В проекте, над которым я работаю, в котором используется Spring, я вижу нечто, что действительно поражает меня. Очевидно, существуют модульные тесты, для работы которых нужны bean-компоненты, и эти bean-компоненты создаются из файлов XML, содержащих такие вещи, как:

<bean class="...ListDTO">
 <constructor-arg>
  <map>
   <entry key="use1key">
    <value>use1value</value>
   </entry>
   <entry key="use2key">
    <value>use2value</value>
   </entry>
  </map>
 </constructor-arg>
 <constructor-arg>
  <map>
   <entry key="nature1key">
    <value>nature1value</value>
   </entry>
   <entry key="nature2key">
    <value>nature2value</value>
   </entry>
  </map>
 </constructor-arg>
 <constructor-arg>
  <value>false</value>
 </constructor-arg>
</bean>

А что случилось? Конструктор класса ... ListDTO изменился, и, следовательно, bean, очевидно, больше не может быть создан из этого (очень многословного IMHO) XML.

Может кто-нибудь объяснить мне, почему это хорошая практика (правда ли?) Помещать такие вещи в XML вместо кода Java? Если бы это было в Java-коде, как только ... ListDTO изменил бы, модульный тест отказался бы компилироваться (даже если часть модульного теста, создающая экземпляр этого компонента, не была выполнена [по какой-либо причине]).

Дополнительный вопрос: есть ли способ легко найти все эти сломанные "bean-компоненты в XML" в проекте, кроме выполнения всех модульных тестов, посмотреть, какие из них не пройдены, а затем промыть и повторить?

Мне кажется довольно серьезной проблемой то, что вы можете изменить конструктор и что среда IDE будет действовать так, как будто все в порядке: что является оправданием для этого? (*)

Ответы [ 3 ]

6 голосов
/ 25 января 2011

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

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

1 голос
/ 25 января 2011

Дополнительный вопрос: есть ли способ легко найти все эти сломанные "bean-компоненты в XML" в проекте, кроме выполнения всех модульных тестов, посмотреть, какие из них не пройдены, а затем промыть-повторить?

Spring Tool Suite или плагин Spring для Eclipse могут проверить правильность файла конфигурации пружины (имеет все параметры конструктора и не используют неизвестные установщики).

0 голосов
/ 25 января 2011

Я думаю, что вы должны использовать инструменты SpringSource при работе с Spring.Вы можете скачать его как отдельно, так и в виде плагинов Eclipse:

http://www.springsource.com/developer/sts

http://dist.springsource.com/milestone/TOOLS/update/e3.6

...