Re: POJOs

Anthony & Melissa Berglas <[email protected]>
Newsgroups gmane.comp.java.orm.simpleorm
Message-ID <[email protected]>
Hello John,

It is rarely a good idea to use POJOs.  If you implement get and set 
methods then the simpleORM records will look just like POJOs externally.

Internally SimpleORM records are an array of objects.  Accessing the 
array is very fast, but there is some overhead in boxing up integers 
and floats into Objects.  If you are accessing a field on the SAME 
object thousands of times then a POJO might be justified.  But that 
is very rare.  If you are accessing a thousand records then the 
creation of POJOs will probably slow you down.

In all these performance issues I strongly suggest that you first 
implement a simple solution, then carefully profile it, and only then 
perform optimizations.  Inevitably the bottlnecks will not be where 
you expect them.

If you do want to create POJOs then write a generic method
   Object createPOJO(class pojoClass, SRecordInstance instance)

I have attached code that does a similar thing for a different 
package (SimpleWebApp) but it demonstrates the general 
technique.   If you write this cleanly with a test case then I will 
add it to the SimpleORM package.

Regards,

Anthony




At 02:35 AM 23/10/2008, you wrote:

>Hello there. I used SimpleORM for some projects a few years ago, but I
>really wanted to use POJOs, primarily because of the sheer volume of
>objects (and resulting memory constraints) but also because I was
>retrofitting an old project that had used plain JDBC calls and custom
>object-creation-from-query routines.
>
>So I tried Hibernate for a while. Turns out, much to my surprise, that
>Hibernate uses "pseudo-POJO's" with a byte-code enhancer. Sucky. :(
>
>Now that I've given up on Hibernate, for that reason and the other
>obvious reasons, and since SimpleORM has had some further development, I
>think I'll go back to SimpleORM. I'll probably use a combination of
>direct JDBC and SimpleORM in the next development cycle, just to make
>sure I'm building on the code that actually works already.
>
>So now I'm left with wondering how to best create POJOs from Hibernate
>objects. For instance, I have a ParcelInterface, representing the
>behaviour of a legal parcel of land in my simulation. I have two
>classes that implement ParcelInterface: SimpleORMParcel, which uses
>SimpleORM, and Parcel, which uses shorts, floats and chars as much as
>possible (instead of ints, doubles and strings) so that I can fit as
>many Parcels into memory as possible.
>
>What I'm wondering about is the best way of creating Parcels using
>SimpleORM. Presumably I'd create SimpleORMParcels simply using
>SimpleORM, and then create Parcels from the SimpleORMParcels.
>
>Perhaps I would have a query that makes 10,000 SimpleORMParcels at a
>time, and then have a method SimpleORMParcel.createPlainOldParcel:
>public Parcel createPlainOldParcel()
>which I would call 10,000 times to create a POJO memory-lean Parcel from
>the SimpleORMParcel.
>
>Or perhaps I would have a static method
>static public Parcel createPlainOldParcel(SimpleORMParcel
>theSimpleORMParcel)
>
>Or perhaps I'd do something completely different?
>
>I realize I should probably read about the Data Access Objects pattern
>(DAO), but I suspect there is "best way" to do it using SimpleORM that
>someone else has already figured out, that they could share with me.
>
>Again, I think I need to use POJOs for three reasons:
>1) to keep memory use down,
>2) to keep speed up (it is a scientific numerical simulation, I
>sometimes use direct field access instead of get() and set() just to
>make things a tiny bit faster)
>3) I have legacy code that uses these POJOs
>
>Perhaps I'm wrong about needing to use POJOs, so advice to the contrary
>is welcome.
>
>Thanks,
>
>--
>John Abraham
><mailto:jabraham%40ucalgary.ca>[email protected]
>


Spreadsheet Detective,
Southern Cross Software Queensland Pty Limited
54 Gerler Street
Bardon, Queensland 4065, Australia.

Email: [email protected]
www.SpreadsheetDetective.com
Ph: +61 427 830248 (Australian Eastern Standard Time)

"If the model seems correct only because the numbers look right,
then why build the model in the first place?"

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
2734d536.jpg (image/jpeg, 3.3 KB) - not displayed
WBeanUtils.java (text/plain, 3.1 KB)
package simpleorm.simplewebapp.core;

import java.lang.reflect.Method;
import java.util.Collection;


/**
 * Very simple get/set properties etc.
 * Can be used in examples, reflection not a core requirement of SimpleWebApp!
 * Not particularly efficient, no caching of method objects etc.
 * (No need for the complexity of java.beans or commons bean utils.)   <p>
 *
 */
public class WBeanUtils {

    /**
     *  Updates fields.values with bean properties in bean.
     *  fields parameters is normally <code>getCrudFields().getValues()</code>
     *  Propeties are methods of form getXxx() where Xxx is the field name.
     *  Note silently ignores fields that do not have properties.
     */
    public static void retrieveBeanProperties(Object bean, Collection<WField> fields) {
        for (WField field: fields) {
            try {
                retrieveBeanProperty(bean, field);
            } catch (NoSuchMethodException nsm) { }
            catch (Exception ex) {
                throw new WException("While retrieving " + field + " from " + bean, ex);
            }
        }
    }

    /**
     * Copies fields.values into bean properties.
     * @see #retrieveBeanProperties
     */
     public static void updateBeanProperties(Object bean, Collection<WField> fields) {
         for (WField field: fields) {
             try {
                 updateBeanProperty(bean, field);
             } catch (NoSuchMethodException nsm) { }
             catch (Exception ex) {throw new WException(ex);}
         }
    }

    /** set this field's value from the Java bean (ie. setValue(bean.getName()).
     * Support for getBeanProperties.
     * Note that there is no real point in calling this directly for an individual property,
     * better just to explicitly call its getter.
     */
    static void retrieveBeanProperty(Object bean, WField field) throws Exception {
        field.setValue(WBeanUtils.getPropertyValue(bean, field.getDataName()));
    }

    /** set the Java bean's property to this field's value (ie. bean.setName(getValue())). */
    static void updateBeanProperty(Object bean, WField field) throws Exception {
        WBeanUtils.setPropertyValue(bean, field.getDataName(), field.getValue(), field.getValueClass());
    }


    /** get(foo, "bar") returns foo.getBar() */
    static Object getPropertyValue(Object bean, String name) throws Exception {
            Method  method = propertyMethod(bean, "get", name, null);
            return method.invoke(bean);
    }

    /** Does bean.setName(value).
     * (clazz parameter is sadly necessary in case value is null.)
     */
    static void setPropertyValue(Object bean, String name, Object value, Class clazz) throws Exception {
            Method  method = propertyMethod(bean, "set", name, new Class[]{clazz});
            method.invoke(bean, value);
    }

    static Method propertyMethod(Object bean, String getSet, String name, Class[] params) throws Exception {
        String mname = getSet + name.substring(0, 1).toUpperCase() + name.substring(1);
        Class c = bean.getClass();
        return c.getMethod(mname, params);
    }
}
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.