I have added the ability to specify an Interface for a table to allow multiple implementations. I do not want torque deciding which methods must be in the interface, so it is assumed to be empty as far as torque generated classes are concerned.
The manager implementation class can be specified in torque's configuration though inheritance is used as opposed to an interface. Do you feel this is too limiting? john mcnally "Hoang, Hai" wrote: > > I really like the idea of having separated the business object and business > object manager into to separated classes for each table. For example, for a > user table you can have the following classes: > > Interface User > Interface UserManager > Class UserImp implements User > Class UserManagerImpl implements UserManager > > Where User contains getter/setter methods and UserManager manages the User > class and its relationship. I am wandering why torque is not follows this > design pattern? The advantage for this design is decoupling. You can change > the persistent layer for whatever reason and all you've to do is > re-implement the UserManagerImpl class. In fact, I see some of the above > idea was implemented in the security service. > > Also, is it worth for me to implement this feature in torque by letting the > UserManagerImpl uses the base/peer classes generated by torque currently. > Since I am new to torque, is there another way to accomplish the same thing? > > Hai Hoang > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
