В чем преимущество динамического создания классов Java-бинов из XML?

Question

Я написал много классов Java-бинов, используя мою IDE. Другой человек предлагает другой подход. Он предлагает, чтобы я поместил XML-файл с определениями бинов в них. Затем я использую jaxb или xslt для динамической генерации классов во время сборки. Хотя это новый и интересный подход, я не вижу в этом особой выгоды.

В этом предложенном подходе я вижу только одно преимущество: классы Java-бина не нужно поддерживать в управлении конфигурацией. Любые изменения bean-компонента потребуют только обновления в xml-файле.

Есть ли какие-либо важные преимущества в динамическом создании классов Java? Есть ли другая причина, по которой этот подход принят?

Answer 1

Я согласен с @Ahilss.Мой опыт был в крупномасштабных проектах Java EE, где генерация кода распространена.

Все зависит от вашего проекта.Если вы кодируете только несколько bean-компонентов и нуждаетесь только в базовых функциях, я не вижу необходимости начинать с XML (который часто так или иначе используется).Особенно, если вам на самом деле не нужен и XML.

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

В качестве контраргумента, с EJB3 и подобными стандартами, теперь часто проще писать бины и генерировать грязный XML-материал на лету.То есть.позвольте серверу выполнить всю тяжелую работу.

Еще одна причина, по которой стоит подумать о генерации кода, - это если вам требуются более сложные функции в ваших компонентах, потому что они представляют структуры данных.Несколько лет назад я опробовал проект Apache Tuscany для создания bean-компонентов SDO из XML.Приятно то, что я мог генерировать такие функции, как уведомления об изменении свойств, поэтому, когда я изменял какие-либо свойства компонента (включая коллекции), другие части вашей программы могли получать уведомления автоматически.Подобная генерируемая функциональность может сэкономить вам много времени и денег, если вам это нужно.

В конечном счете, я бы предложил придерживаться принципа KISS.Так что не добавляйте то, что вам не нужно.Сгенерированный код из XML полезен, если он поможет вам в долгосрочной перспективе.Но, как и любая технология, убедитесь, что вы добавляете ее по правильным причинам.

Answer 2

Я использовал Jibx и его генератор в своем проекте.Мой опыт был неоднозначным.

1. Обычный случай использования генератора JAXB (XJC) упоминается в http://static.springsource.org/spring-ws/site/reference/html/why-contract-first.html Преобразование в и из XML делает возможным его сохранение вБД и извлечение для будущего использования, а также для ввода тестового примера для функциональных тестов.

2. Использование любого типа генератора (Jaxb, Jibx, XMLBeans, Custom) может иметь смысл для больших размеровпроекты.Он позволяет стандартизировать типы данных (например, BigDecimal для финансовых сумм, например, ArrayList для всех списков), форсировать интерфейсы (например, Serializable или Cloneable).Это обеспечивает соблюдение передового опыта и снижает необходимость проверок сгенерированных файлов.

3. Это позволяет внедрить код через XSLT или постобработать сгенерированный файл Java.Примером является внедрение кода округления до определенного десятичного размера (2,6,9) с определенной политикой (UP, DOWN, NEAR) в методе сеттера для каждого поля типа financialAmount.Принуждение к такому поведению уменьшает количество ошибок (из-за неверных финансовых значений, за которые компании несут ответственность).

Недостатком является

1. Обычно каждыйКласс Java может быть только классом бина.Любая сделанная настройка будет перезаписана.Поскольку (в моем случае) генератор привязан к процессу сборки.Классы генерируются при каждой сборке.

2. Вы не можете реализовать свои пользовательские интерфейсы в классе компонента или добавить аннотации для собственных или сторонних фреймворков.

3. Вы не можете легко реализовать шаблоны как фабричный метод, так как обычно создаются конструкторы по умолчанию.Рефакторинг обычно затруднителен, поскольку генераторы обычно его не поддерживают.

4. Вы можете (не уверен сейчас, правда, пару лет назад для Jibx) не могли генерировать ENUMS, когда это будетбыть наиболее применимым.

5. Возможно, вы не сможете переопределить тип данных по умолчанию своим собственным, независимо от необходимости.CopyOnWrite, а не ArrayList для переменной, совместно используемой потоками, или пользовательская реализация List, которая также реализует шаблон Observer.

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

Для проектов меньшего размера я лично написал бы свои собственные классы.Для крупных проектов я бы не стал использовать его на среднем уровне в основном из-за отсутствия поддержки рефакторинга.Его можно использовать для простых bean-компонентов, предназначенных для привязки к инфраструктуре пользовательского интерфейса.