The "problem" of Object mapping is not unique to XML.
It is common nowadays for ORM tools to Relational DB's to be favored, and once learned seems the "natural" way to deal
with any kind of data. I remember a couple years back working with a co-worker and I was to take over his code,
it had to do a tiny tiny bit of SQL to Oracle (maybe 2 calls - would be about 20 lines of JDBC or so ) so in order to do this the source pulled in about 100
MB of Hibernate runtime. I asked why he needed hibernate for this and the answer was "I have long stopped writing JDBC in java by hand" ... Now the funny part was this code was doing a bit of XML work as well and he used DOM ...
and my answer to that was xmlsh could do both the SQL AND the XML work in about 1000th the LOC so I told him
"I've stopped writing XML processing in Java by hand" ...
So anyway humor aside ... I am a bit on the fence about this whole object mapping thing.
What many (most?) programmers are learning/taught is that to deal with any data at all, you use a tool that brings the data into an object in your language,
muck with it and write it back out and are saved all the ugly work of having to figure out what is done under the hood. This is not always a bad paradigm, although I tend to avoid it ... But I can see the temptation.
Especially if you havent had time to learn the whole stack of TechnologyX ... it can seem daunting and "just wrong" to get your hands dirty with the underlying
stuff ... that's why there are mapping tools right ? And it's what "everybody does" so you can't go wrong.
And sometimes it is right ... ever try to do soap and wsdl without mapping tooling ? (yes I have ... and its possible ...) but its really hard and chances
are it won't work without some magic pixie dust only the Microsoft/Sun gurus know about and slipped into the specs at line 4billion305 ... If your initial experience with XML is like that, or say looking at a Word document ... you may very rightly decide
it's not worth it to learn another way when you can just toss a mapping layer on and be on your way.
Software has gotten so complicated that most people simply dont have the time in their entire career to learn everything,
so they pick what they want to learn, what their boss tells them to learn and for the rest pick what seems easiest - and if it works you stop there. And for
a lot of people that is not bad or wrong. The universe of programmers is not what it was 30 years ago. There is a huge amount of jobs for people to "just" put together pre-built parts. Expecting everyone to be an expert at everything is unrealistic.
And face it, you *do* have to know XML quite well to use the "simple" tools ... and when to choose them over more complex tools.
When do you pick DOM or SAX or StAX or XSLT or XQuery or xmlsh or XPath or XProc ? To actually make a useful decision on this you actually have to learn ALL
of them ... It is daunting ... and if you're not an XML Specialist you are likely to pick the wrong tooling first, find out it doesnt work well for your job at hand ... then what ?
Or you toss a mapping layer on top of everything and pretend it's not there and your job gets done before your slip deadlines and get fired.
-David
----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org
Cart
