db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Hainlin <dhain...@comcast.net>
Subject Re: question on Torque's limitation
Date Wed, 02 Jul 2003 02:28:29 GMT
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: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org

View raw message