db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Bauman <g...@bravenet.com>
Subject Re: question on Torque's limitation
Date Tue, 01 Jul 2003 20:55:19 GMT
> 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.


View raw message