All,
I agree with many points in this email. I am using a lot of JAXB in my
applications. Mostly I use it to load in properties files, like files
with queries and validation fields, etc... Since these files are loaded
in at the time of app server start up, performance is not a major factor
for me either. I am not saying its poor, I just didn't really have to
consider it. Once the server is up, I am just talking w/ domain
objects.
In one instance I am storing a stateful application as XML. Users can
fill out the application in stages and in many different sessions, thus
I have to be able to easily jump into the middle of my XML file. The
end goal is that the XML is converted in MISMO standards using XSL and
going to be sent over the wire as a web service for underwriting, credit
reports, etc... Its a lot easier to call setBorrower() and pass a
domain object instead of traversing DOM and placing it in the right
area. Validating my own DOM code would be 10X tougher.
other points in-line.
Regards,
Andrew Wellman
>
> When you read an xml document in java you take the data that you find,
> and either create objects with it, or pass it to objects; in either
> case you're giving it to objects that will internalise and encapsulate
> it.
Yes, Yes, Yes. Who wants to write DOM/SAX code? It is very ugly and
not
maintenance friendly code.
>
> If you just use the data directly then you're not developing in the OO
> paradigm, and perhaps shouldn't be using java. If you're just taking
> the data, and creating new xml documents out of it, then you should be
> using xsl. But, if you are writing an OO system, then you'll want to
> put the data into domain objects - objects that model the solution
> domain of you system(classes like Customer, Address, etc).
I also agree with this. Its nice to have an object that I understand as
the end product, as opposed to having to look at schemas or DTDs all day
to understand my data.
>
> Right now you're writing DOM or SAX code to read the xml document, and
> writing code that takes the resulting data and puts it into the domain
> classes. This is what JAXB does for you. It creates entity classes
> that you can use from your domain classes.
You would hope that the code ends up in Domain classes. If not its even
more poor than just SAX/DOM.
>
> Your schema may change, but your domain model will probably remain
> fairly static. In this scenario, when the schema changes you'll
> generate a new entity model and make the relevant changes in your
> domain model to access it. This could be as simple as changing a
> single attribute name. If you were using DOM or SAX then you'd have to
> change a lot more, write tests for it, run the tests, fix the
> implementation, run the tests again, refactor, etc.
>
> There are other benefits too. If you *can* assume that the JAXB
> implementation you're using generates defect free code, then you don't
> have to spend time testing that code, and you don't have to look there
> for defects when they arise in your system. Everything you write by
> hand you have to distrust, test, and continually confirm.
Exactly! Its almost like having your own pre-defined component. Since
there
are several vendors doing JAXB you have a choice of who ever puts out
the
best product. This will especially true as it becomes standardized.
>
> The arguments for using JAXB over DOM or SAX where a schema is
> available are persuasive. I can find no good reason to directly use
> DOM or SAX again.
I have some legacy SAX that I am too lazy to migrate, but that's it.
Otherwise,
I use JAXB and XSL as frequently as possible.