> In either case, the answer is the same. Why remove
> functionality when it
> costs you nothing to leave it in?
Cost is relative. Adding abstract gains you code clarity. Not everyone is
going to be as clued in, so if you prevent just one bug, odds are that
adding one word paid out a whole lot.
<snip>
> A few months back, someone posted a tool named ObjectVisualizer
> (http://www.opensourcesoft.net) that would load cayenne classes using
> introspection into a visualizer tool. A big problem with it
> was that it
> created objects at the CLASS level rather than at the _CLASS
> level, causing
> all sorts of side effects with business logic in the CLASS
> file when it
> could have all been avoided using the _CLASS file. Of course
> it possibly
> could have also been done using CayenneDataObject, but
> there's no easy way
> to pull out the keys.
>
Interesting. You and Andrus are somewhat at odds here, but I'm compelled to
think that you have a good point :) Potentially this is another case for a
parameter to the generator, but probably not or there will be more options
than generated code.
One thought that crossed my mind, though - is there an argument to be made
that tools such as ObjectVisualizer should not bypassing the business logic?
Problems incurred due to business logic typically smell of problems in
design to me. Not always, of course...
Oh, and just to clarify, I did mean the _Entity objects.
Cris
This archive was generated by hypermail 2.0.0 : Tue Mar 08 2005 - 09:51:16 EST