Hi, We've extended OJB to use an instantiation factory (a-la TopLink). Using an instantiation factory is very useful when you want to register objects and also to differentiate between objects that were created from the DB to objects that were created from the App (solves INSERT or UPDATE problem for example, also helps when it comes to caching). It can also be used to fetch objects from object pools instead of using constructors (although I doubt the performance increase here).
Attached is our solution, which replaces the row reader with a new one. It also adds a new confioguration key: InstantiationFactory. Documentation is scarce though. I'd be more than glad if it would be added to the CVS :) Thanks, Tal Note: I've done some manual refactoring to remove other infrastructure code that isn't OJB so there might be a few typos. Package names have to be renamed aswell ... -----Original Message----- From: Ganguli Jaideep [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 16, 2003 4:26 PM To: OJB Users List Subject: [vote] Re: Constructor for Domain Objects it was possible for me > to prevent the Domain Object api developers from being able to create > the object in an 'invalid' state. I had 'static' methods which took arguments to create valid instances for e.g. Lets say i had a 'Customer' Domain object with 2 attributes 'name' and 'phone' and both name and phone are 'required'. In the Customer class i would make the constructor private. I would also provide a 'public static Customer newInstance (name, phone)' method that allows api users to create new customers. For existing customers the OR Mapping tool will create the Customer instance using the private no arg constructor using reflection and load it with the name and phone data originally set. So, this way you can prevent the domain object api developers from being able to create a Customer Object with the name and phone not set. (They would otherwise be able to do it using a public default no arg Constructor). hope this helps Jaideep Ganguli Jaideep wrote: > > > Let's have a little vote > > Do we need support for > > a) private no argument constructors? > > +1 > > Here's the reason why i thought it as 'something i need'. > > With a private constructor I was able to build a it was possible for me > to prevent the Domain Object api developers from being able to create > the object in an 'invalid' state. > > So, basically it helped me to create a cleaner domain object api. > > Thanks > > Jaideep Ganguli > > Thomas Mahler wrote: > > > > hi all, > > > > Ganguli Jaideep wrote: > > > Hi all, > > > > > > Is it absolutely necessary to have a public no argument constructor for > > > my domain objects? > > > > > > I have worked with another OR Mapping tool before (Toplink) where this > > > was not necessary. It still needed a no argument constructor, but the > > > constructor wasn't required to be public, it could be private. > > > > > > > The main reason to rely on a public constructor was performance. If > > there is no public constructor you'll have to do some additional > > reflection magic to make construction possible. > > > > We wanted to keep things simple, thus we also don't have a feature to > > specify factory classes and methods to construct domain objects. > > > > Let's have a little vote > > Do we need support for > > a) private no argument constructors? > > > > b) userdefined factories to build domain objects? > > > > cheers, > > Thomas > > > > > Thanks > > > > > > Jaideep > > > > > > -- > > > 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]> > > -- > 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]>
RowReaderImpl.java
Description: Binary data
InstantiationDefaultImpl.java
Description: Binary data
InstantiationFactory.java
Description: Binary data
Instantiation.java
Description: Binary data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
