Lists Home |
Date Index |
> This assumes data binding in a statically typed language
> which seems to
> me to imply overly tight coupling.
I didn't mean to imply there weren't correspondingly big losses, too. :-)
I actually implemented a path-based (though not expression based)
accessor/mutator scheme for XML data instances stored in a simplified DOM.
Within a month the GUI developers were screaming for my head on a platter.
Under extreme duress I had to write a proxy layer of so-called real data
objects on top of the data access objects. It added 30% more work to my
development and maintenance effort.
And still, all validation was a runtime (via type checking against stored
schema info [Holy shades of primordial PSVI, Batman!]), which meant in
addition to writing proxies, I had to write unit tests. Not a bad idea in
itself, but I had to run them every time I made even the simplest change to
the data model, which added more time to development.
That's why I see data binding as an improvement in that situation, although
none of the data binding tools are all that mature as of yet. And there's
always going to be a disconnect between types specified in an XML Schema (or
what have you) and the primitive types in some programming language.
I think what you have to be careful about is not so much the tight binding
between the XML Schema and generated data objects, but tight binding between
the rest of your application code and those generated objects. That's where
interface-based generative approaches like JAXB offer some ability to buffer
data model change impact. It's especially synergistic with Java 1.4 dynamic
> However given the popularity of
> Object<->XML binding technologies it seems that most developers would
> forego the loose coupling that many would consider a benefit of XML to
> gain an easier processing model.
Some people just don't want to fiddle with mundane data representation
issues, and other people (like me) don't like the pixelated perfectionism
required of professional GUI programmers. Unfortunately we have to work