[
Lists Home |
Date Index |
Thread Index
]
> No, no help at all. It's not a problem that you solve by
> trying to use another
> Java feature. The problem is if the auto-generated XML->Java
> code is called
> from all throughout the application codebase.
That's a design failure, not a problem due to code generation. Any data
model is likely to change, whether it's hand-crufted (er, crafted) data
objects or auto-generated data objects.
There are low-level data objects and high level business objects. Low-level
data objects are more or less directly persisted, and are highly granular
(in a sense "normalized objects'). High-level business objects are
aggregates of these, and help insulate the rest of the application from
changes in the data model. On top of the business objects are built the UI
and control code.
The one objection I see as valid is that XML Schema datatypes are not Java
(or C++, or Smalltalk) datatypes. The best you can do is approximate them
in generated code.
> You need to hide the auto-generated code behind a
> facade so that almost
> all of the application code is unable to call it directly.
Well, okay: I just got done expounding upon what you said. :0)
But in order to create facades, its a necessity to code the facade to
generated interfaces, rather than extend them from generated objects
directly. That was my point, so I think we're in agreement after all.
|
