Re: question on Torque's limitation

[David Hainlin]

Have to jump in on this one.  While I agree with everything said about 
Torque's limitations and orientation, my experience with it couldn't 
have been more different.  I recently had to integrate with Oracle 11i 
HRMS stacks and Torque saved me much grief.  I never even looked at the 
Veliocity based generators and I ended up with some fairly complex 
business objects layered on my Torque classes.  Could have rolled my own 
with JDBC but it was such as joy to simply let the simple (and trouble 
free) Torque code handle it.  I did have to do some gyrations around 
joins but a few materialized views fixed that right up.  Torque is 
simple and not very rich.  It in no way stands up as a full featured OR 
mapper but in some situations, it can be a life saver. Especially if you 
are strongly table oriented, Torque is a pretty good and solid DAO 
layer. YMMV.

Gabriel Bauman wrote:

I think the problem is that you and I are trying to apply Torque (or 
any other O/R mapper) to a problem it's just not made for.  Certainly 
in our case, I do have trouble seeing the practical application of 
Torque, because the *implicit* / *business process defined* O/R map 
for our ERP is hella complex.


I think you've hit on it. Torque is really table-oriented, not 
business-object oriented. If there's any lesson I can take away from 
the last few months of wrestling with Torque, it's that table 
structure should be designed around business objects, not used as the 
basis for business entities (as Torque seems to encourage). Business 
objects should practically never be modified to suit some quirk of 
their persistent storage mechanism. This is probably pretty obvious, I 
must have been on stupid pills for the last few months. Hindsight.

In my application, Torque has been reduced to a very basic DTO layer. 
I don't put any logic in any of the generated classes and I use only 
the storage methods.

I intend to remove Torque entirely and go back to populating objects 
using SQL. When Torque works, it works all right... but the code 
generation stages are one big time consuming headache while debugging. 
And debugging Velocity that generates Java really, really, REALLY sucks.

I have glanced at Hibernate over the past week, and it looks like a 
good alternative to Torque. I think I'll skip it though. SQL is fine 
for now in my case.

Gabe

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]