Я считаю, что использование XML в конфигах — зло и малодушие. Далее попытаюсь обьяснить почему.
Почему пытаются использовать XML? «Потому, что не надо быть программистом, чтобы его редактировать». Но это чушь! Я не видел простых людей (не программистов), которые бы правили xml сами! Ни одна IDE не спасёт от того, что в один прекрасный день тебе придётся лезть руками в XML файл и править одни закорючки на другие.
Теперь давайте рассмотрим чем такое малодушие и промывание мозгов выливаются для таких простых разработчиков как я.
Основным минусом является то, что в XML конфигах нет возможности использовать давно знакомых и удобных ООП приёмов: наследованиия и полиморфизма.
Рассмотрим пример. Есть два web.xml файла, часть конфигурации (обьявления сервлетов, параметров, фильтров и тд) находится в одном, часть — в другом.
Так вот — средствами web.xml их НЕ ОБЬЕДИНИТЬ. Такая элементарная операция!..
Что бы я сделал если бы конфигурирование производилось путём вызова некоторого Factory метода? Я бы создал класс предок WebA
и класс потомок WebB
После этого всё, что нужно — создать свой конфиг:
ВСЁ! Это элементарная операция в Java (да что там — в любом ЯП) практически невыполнима в XML.
Конечно и XML формат можно развить настолько, что в нём можно будет делать почти всё то же самое, что и в обычном ЯП. Например в maven-овском POM формате предусмотрено некоторое «наследование для бедных», путём указания тэга «parent».
В принципе в maven-е ты можешь унаследовать такие вещи, как dependencies. Но вот то, что находится внутри тэга «build» — никуда не унаследуется! Просто разработчики формата так далеко не смотрят, для типичного проекта это не надо. А на практике это как правило выливается в использование copy-paste технологии.
Так какой из это всей херни следует вывод? Вывод такой — как только у тебя появляется конфиг чуть более сложный, чем указание factory метода — сразу переноси конфигурацию из XML в нормальный ЯП (заменяя Schema-у на API) иначе будешь постоянно мучаться, реализовывая все стандартные фишки языка программирования в своём XML формате.
Почему пытаются использовать XML? «Потому, что не надо быть программистом, чтобы его редактировать». Но это чушь! Я не видел простых людей (не программистов), которые бы правили xml сами! Ни одна IDE не спасёт от того, что в один прекрасный день тебе придётся лезть руками в XML файл и править одни закорючки на другие.
Теперь давайте рассмотрим чем такое малодушие и промывание мозгов выливаются для таких простых разработчиков как я.
Основным минусом является то, что в XML конфигах нет возможности использовать давно знакомых и удобных ООП приёмов: наследованиия и полиморфизма.
Рассмотрим пример. Есть два web.xml файла, часть конфигурации (обьявления сервлетов, параметров, фильтров и тд) находится в одном, часть — в другом.
<?xml version="1.0" encoding="UTF-8"?>
<web-app>
<filter-name>filterA</filter-name>
<filter-class>ru.FilterA</filter-class>
</web-app>
<?xml version="1.0" encoding="UTF-8"?>
<web-app>
<filter-name>filterB</filter-name>
<filter-class>ru.FilterB</filter-class>
</web-app>
Так вот — средствами web.xml их НЕ ОБЬЕДИНИТЬ. Такая элементарная операция!..
Что бы я сделал если бы конфигурирование производилось путём вызова некоторого Factory метода? Я бы создал класс предок WebA
public class WebA implements WebConfig {
...
}
и класс потомок WebB
public class WebB extends WebA {
...
}
После этого всё, что нужно — создать свой конфиг:
<web-conf configClass="WebB" />
ВСЁ! Это элементарная операция в Java (да что там — в любом ЯП) практически невыполнима в XML.
Конечно и XML формат можно развить настолько, что в нём можно будет делать почти всё то же самое, что и в обычном ЯП. Например в maven-овском POM формате предусмотрено некоторое «наследование для бедных», путём указания тэга «parent».
В принципе в maven-е ты можешь унаследовать такие вещи, как dependencies. Но вот то, что находится внутри тэга «build» — никуда не унаследуется! Просто разработчики формата так далеко не смотрят, для типичного проекта это не надо. А на практике это как правило выливается в использование copy-paste технологии.
Так какой из это всей херни следует вывод? Вывод такой — как только у тебя появляется конфиг чуть более сложный, чем указание factory метода — сразу переноси конфигурацию из XML в нормальный ЯП (заменяя Schema-у на API) иначе будешь постоянно мучаться, реализовывая все стандартные фишки языка программирования в своём XML формате.