Building my own data-binding method

Question

Hi,
After looking at the various packages that allow you to do data-binding I have decided for my case it's just simpler (number of lines) to do something myself.
If I have an XML that has fields a through f, which correspond to A through F in MySQL fields. What's the best way to connect these two?
What's the best type to build this thing in? Maps, HashMaps, or Collections? I just don't know the advantages/disadvantages to each obviously.
Thanks.

Answer 1

amirzadeh wrote:
jschell wrote:
My question wasn't clear.
For example if you have a customer entity and has one telephone number and now the users want it to have two telephone numbers then you must add a column to the database. And if you do a B2B xml with that data then you must upgrade the XML to add that new field.
That process is replicated in about 99.9% of all business processing and most of that does not need a runtime solution to the problem.
So the question becomes
1. How often do the requests arrive?
2. What is the nature of the request - how complex is it?"We would like to have dataPoint123 added to the excel file that we get every day" sort of thing, so we have to check to see if we have the data stored in the database, if not than we have to go back to the appliance and add it to the XML report that is generated. Than add it to the database to be stored. Modify the import of the XML code. Add in the data processing portion of the code if need be, add it to the export report.
If you are doing 50 of these a day and they are all simple then your design if flawed because you cannot continue to add that many columns to existing tables. This is further complicated if you are differentiating it by user (some users have different fields from others.) Again it would still represent a design flaw.It's more like 1 every two to three weeks. And since we don't touch the code every day it becomes a pain when something like this has to change, because we have to go find it in the 17 different places it needs to be touched.
The phrase "17 places" suggests a disconnect with what you described above. With "17 places" you have at a moderately complex change request.
And your description above doesn't sound like something that you can pattern.
If I have a database with tables/columns and the users request a change to a report frequently which originates with existing data then automating the report creation might be a worthwhile project. Myself with the given timeline I would opt for code generation rather than a runtime solution.
However if the data doesn't exist then you MUST rollout a code change. The DDL must change, you must have code to populate it, and perhaps other business rules are added. And that is unlikely to be something that can be patterned. Actually only way that could be patterned would be in a flow through system (source in => database => report)
>>
If on the other hand you get one of these every 6 months then you do not need a dynamic solution (at all.)I don't agree with the statement, I think "dynamic" nature of code is even more important with code that you don't touch/live with every day. I have C code that I live with every day, it's always been improved and worked on, I rarely do anything majorly dynamic in there, because I don't need it. It's faster than I need it to be, the foot print is small comparatively and it is changes too often to try to modularize it.
That paragraph seems contradictory. Or maybe it is a terminology issue.
"Dynamic" for this discussion relates to code generation, generalization (adding complexity in tradeoff for power), metadata type solutions, etc.
That said maintenance is the highest cost in software development. To maintain code someone must understand it. Adding a "dynamic" solution (above definition) into code means that it will take longer to find and fix bugs. And without rigorous process control over time it is likely to lead to more 'hacks' because someone couldn't figure out the correct way to fix something or because the existing design didn't allow for it and they didn't refactor.
Thus one must consider the tradeoffs carefully.
Note that with code generation one can achieve simplicity with ease of use. I do this commonly because I do not want to require other developers to understand the code creation process. So I create code generation tools to ease my work but check in the generated code so that if some other developer needs to maintain it they can work with that. I check in the tools to but at the point where they start maintaining the code it is their choice which route to use.