从xml动态生成java bean类有什么好处？ [英] what is the benefit in dynamically generating java bean classes from xml?

问题描述

我使用IDE编写了很多java bean类。另一个人建议采用不同的方法。他建议我在其中放置一个带有bean定义的xml文件。然后我使用jaxb或xslt在构建期间动态生成类。虽然它是一种新颖而有趣的方法，但我认为它没有任何重大好处。

我认为这种建议的方法只有一个好处：java bean类不需要在配置控制中维护。任何bean更改都只需要在xml文件中进行更新。

动态生成java类有什么重大好处吗？是否有其他原因可以采用这种方法？

解决方案

我在项目中使用了Jibx及其生成器。我的经验好坏参半。

1. 使用JAXB（XJC）生成器的常见情况见 http://static.springsource.org/spring-ws/site/ reference / html / why-contract-first.html
   与XML的转换使得可以存储在数据库中并检索以备将来使用，以及用于功能测试的测试用例输入。 / p>




2. 使用任何类型的生成器（Jaxb，Jibx，XMLBeans，Custom）可能对大型项目有意义。它允许标准化数据类型（如财务金额的BigDecimal，如所有列表的ArrayList），强制接口（如Serializable或Cloneable）。这可以强制执行良好实践并减少对生成文件进行审核的需要。




3. 它允许通过XSLT注入代码或生成java文件的后处理。示例是对于financialAmount类型的每个字段，使用setter方法中的特定策略（UP，DOWN，NEAR）将舍入代码注入特定的十进制大小（2,6,9）。强制这种行为确实减少了错误的实例（对于公司负责的不正确的财务价值）。

缺点

1. 通常每个java类只能是一个bean类。任何自定义都将被覆盖。因为（在我的情况下）生成器绑定到构建过程。这些类是在每次构建时生成的。




2. 您不能在bean类上实现自定义接口，也不能为自己的或第三方框架添加注释。 / p>




3. 由于通常会生成默认构造函数，因此无法轻松实现工厂方法之类的模式。重构通常很困难，因为生成器通常不支持它。




4. 你可能（现在不确定，几年前Jibx是真的）不能生成ENUMS最适用的时候。




5. 无论是否需要，您都可能无法使用自己的数据类型覆盖默认数据类型。 CopyOnWrite列表而不是ArrayList，用于跨线程共享的变量或List的自定义实现，它也实现了Observer模式。

发电机的好处超过了大型（人员而不是代码，认为三个地点的150名开发人员）分布式项目的成本。您可以通过定义包含bean的自定义类并实现行为或后处理（添加其他代码）以及从XSD注释或其他配置文件中获取的其他元数据来解决这些缺点。记住发电机的支持和维护变得至关重要，因为整个项目依赖于它。请谨慎使用。

对于规模较小的项目，我个人会编写自己的课程。对于规模较大的项目，我个人不会在中间层使用它，主要是因为缺乏重构支持。它可以用于意图绑定到UI框架的简单bean。

I had written a lot of java bean classes using my IDE. Another person suggests a different approach. He suggests that I put an xml file with bean definitions in them. Then I either use jaxb or xslt to dynamically generate the classes during build time. Though its a novel and interesting approach, I do not see any major benefit in it.

I see only one benefit in this suggested approach : The java bean classes need not be maintained in configuration control. Any bean changes is going to require only an update in the xml file.

Are there any major benefits in dynamically generating java classes ? Is there any other reason why this approach is taken ?

解决方案

I have used Jibx and its generator in my project. My experience has been mixed.

1. The usual case for using JAXB's (XJC) generator is referred to in http://static.springsource.org/spring-ws/site/reference/html/why-contract-first.html Conversion to and from XML maked it possible to store in the DB and retrieve for future use as well as use for test case input for functional tests.

2. Using any kind of generator (Jaxb,Jibx,XMLBeans,Custom) might make sense for large sized projects. It allows for standardization of data types (like BigDecimal for financial amounts, like ArrayList for all lists), forcing interfaces (like Serializable or Cloneable). This enforces good practices and reduce the need for reviews of generated files.

3. It allows for injection of code through XSLT or post processing of generated java file. Example is to inject Rounding code to a specific decimal size(2,6,9) with a specific policy (UP,DOWN,NEAR) within the setter method for each field of type financialAmount. Forcing such behavior does reduce the instance of bugs(for incorrect financial values which companies are liable for).

The disadvantage are

1. Usually each java class can be only a bean class. Any customization made will be overwritten. Since (in my case) the generator is tied in to the build process. The classes get generated with every build.

2. You cannot do implementation of your custom interfaces on a bean class or add annotations for your own or third party frameworks.

3. You cannot easily implement patterns like a factory method since default constructors are usually generated. Refactoring is usually difficult since generators do not usually support it.

4. You may(not sure now, was true a couple of years ago for Jibx) not be able to generated ENUMS when it would be most applicable.

5. You may not be able to override the default datatype with your own regardless of the need. CopyOnWrite list and not ArrayList for a variable shared across threads or a custom implementation of a List which also implements the Observer pattern.

The benefits of a generator outweigh the costs for large sized (in persons and not code, think 150 developers in three locations) distributed projects. You can work around the disadvantages by defining your custom classes which contain the bean and implements behaviour or post processing (adding additional code) with further metadata picked up from XSD annotations or another configuration file. Remember support and Maintenance of the generator become critical since the entire project depends on it. Use it with CAUTION.

For smaller sized projects I personally would write my own classes. For larger sized projects I personally would not use it in the middle tier mostly because of the lack of refactoring support. It can be used for simple beans meant to be bound to UI frameworks.

这篇关于从xml动态生成java bean类有什么好处？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！