Почему не надо заново компилировать программу при использовании xml конфигурации
Начал знакомиться с Spring. Понял, что можно делать инверсию управления (IoC) через Java код, через аннотации и через xml файл. И как я понял, разница в том, что при изменении xml конфига программу не нужно перекомпилировать, а меняя код или аннотации, очевидно, приходится заново генерировать байт-код.
Я не могу понять, почему все же программу не нужно компилировать снова, используя конфиг. Как происходит подстановка? То есть во время работы программы происходит обращение к xml и его считывание?
P.S может быть это очень глупый вопрос и очевидный, но я пока новичок :(
Ответы (1 шт):
Да, xml конфигурация spring используется во время выполнения программы. Когда программа создает экземпляр контекста и указывает, что конфигурация контекста хранится в xml, то spring читает xml файл(ы) и использует их для создания бинов, внедрения зависимостей и т.д.
Что касается компиляции, то все немного сложней. Если вы меняете только xml файл с конфигурацией, то, действительно, не нужно компилировать java код, ведь там изменений нет.
Однако, в этом случае программа, это не только java код. xml конфигурация является существенной частью программы, в том смысле, что без нее, ваша программа по просту не сможет запуститься. И в зависимости от того, как упакована ваша программа и как она запускается, может потребоваться сборка программы.
Когда вы запускаете программу из IDE (типа eclipse или IDEA), то при изменении xml обычно вообще никаких действий не нужно делать, так как IDE запускает программу из файлов "по месту", т.е. IDE создает такой classpath при запуске вашей программы, что файлы ресурсов (к которым относятся и файлы xml конфигурации spring), берутся прямо из того место, где они находятся в файловой системе.
Когда же вы собираете jar файл, который будет запускаться на сервере (если это серверное приложение) или у пользователя (если клиентское), то файлы ресурсов типа xml конфигурации упакованы в jar файл, и соответственно, измененный xml файл нужно туда заново упаковать (скомпилированные же классы можно использовать те же).
разница в том, что при изменении xml конфига программу не нужно перекомпилировать,
Это не главное различие и преимущество. И не главный критерий, по которому стоит выбирать, какой подход использовать.
Если вы используете java конфигурацию, то у вас меньше зависимость от IDE, то есть не нужна особая поддержка spring со стороны IDE, так как контроль использования классов делается на этапе компиляции. Представьте, что вы переименовываете класс используемый в конфигурации. Для java конфигурации, это сразу приведет к ошибке компиляции и вы это не пропустите, а для xml конфигурации, нужно поддержка со стороны IDE, чтоб это не пропустить, и в худшем случае вы это увидите, только в runtime.
И переименования это только пример, другие операции такие как навигация по коду поддерживаются в IDE гораздо лучше для java, чем xml конфигурации.
Т.е. с этой точки зрения java конфигурация лучше.
Что касается использования xml против аннотаций, то тут тоже есть плюсы и минусы. Использование аннотаций интрузивно, т.е. заставляет менять сам код приложения. С одной стороны это удобно, т.к. в коде класса сразу видно, что он является, например, спринг сервисом, опять же навигацию по коду упрощает. Но с другой стороны это добавляет зависимость на инфраструктурный код (коим является spring) в те слои, где его по-хорошему, быть не должно.
Использование же xml позволяет сделать конфигурацию полностью внешней. Так же это позволяет использовать в качестве бинов классы, которые вы в принципе не можете менять, например из чужой библиотеки, которая про spring вообще ничего не знает.
Ну и последнее, вы не ограничены только xml или java-конфигурацией или аннотациями. Их можно комбинировать, т.е. например, включить файл с xml конфигурацией в класс с java конфигурацией. Или использовать аннотация для сервисов, которые вы сами пишете, а основную конфигурацию держать в java или xml (в которой создавать бины из 3rd party библиотек). Все гибко и возможности безграничны.