Sounds interesting. I like to concentrate on developing my objects and how they behave and sprinkle in persistant storage later. It might be interesting to have torque generate an interface layer and then one implementation based on torque internals. This way all the torque could really be hidden from the user of the interfaces. This may also provide the ability to generate a mock implementation for testing code that uses these objects. Or even some other persistance mech, xml, serialzation, etc.
================================================================= Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com > -----Original Message----- > From: Stephen Haberman [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 22, 2002 10:38 AM > To: [EMAIL PROTECTED] > Subject: refactoring the om templates into separate classes > > > On the project I'm working on, we're using Torque, but we ended up > writing fairly thin wrappers over the main objects we wanted to use as > while behind the scenes we wanted the cool save/relationship > methods, we > didn't want to be freely passing those through our API. > > And now again, I'm in another spot where essentially I want > the user to > pass in just the data for an om object, without having all the fancy > save/relationship methods that they could screw up. > > So, what if instead of all of the om functionality being in one huge > base class, it was split up and tied together via an > inheritance chain? > E.g., something like: > > BaseXxxData - just fields and accessors > BaseXxxStore - extends BaseXxxData, adds save/delete > BaseXxxRel - extends BaseXxxStore, adds the foreign key methods > > So, based on the build.properties, Torque would generate and hook the > classes up as needed and anchor them into BaseXxx. (e.g. if > addSaveMehtod = false but complexObjectModel = true, the > chain would be > BaseXxxData -> BaseXxxRel -> BaseXxx). > > Somehow BaseXxxRel would have to be smart enough to know whether it's > inheriting BaseXxxData or BaseXxxStore as to whether it > should skip the > save method, or override it and add in it's coll logic. > > The two negative points I can think of are: > > - Even more BaseXxx files. But if this is an issue for users, it could > be handled by pushing the Base files off into a separate jar. > > - The possible two-three layers of inheritance per om object > might hurt > performance? I don't really know about this one. > > A few positive points I like are: > > - Better separation of logic in the templates > > - Being able to work with just the BaseXxxData (or perhaps XxxData) > object...e.g. have that as an input parameter to the business logic in > Xxx or Yyy so that you get the convenient data holder without users > potentially abusing it. > > Hm...though what if most of the BaseXxx objects were package private? > I'm surprised they aren't already? > > > Thanks, > Stephen > > > -- > 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]>
