Ian, One possible workaround that we could quickly implement.
All POJO's extend a empty common base class (e.g. OpenSocialBase). You implement your own OpenSocialBase in the same package which extends CayenneDataObject and make sure it preceeds the Shindig one in your classpath. The real question is how much logic will need to reside in the POJOs, data validation etc... If its a lot and we are forced to go the interface route it will move into utility classes to allow you to make use of it when you implement the interfaces. If the POJOs have almost no logic then interfaces are probably the way to go. -Louis On Sun, Apr 20, 2008 at 10:54 AM, Ian Boston <[EMAIL PROTECTED]> wrote: > If I use Cayenne to do the ORM, then it needs to have an integration point > to the model its trying to implement. Cayenne uses class extension... all > data objects must extend CayenneDataObject, so if the model is interfaces I > can create pojos that work in the ORM and are usable in the services. If > they are classes, I cant. > > I could use the pojos, and copy into them from the orm, but that would > increase the volume of objects going through the JVM GC cycles and could > eliminate potential optimizations (lazy load, caching, transactional caching > in the orm) > > I could use another ORM that just uses Pojos, like hibernate, but that can > be nasty since most of them generate really nasty SQL, and I have some bad > experiences. > > or I could use JDBC direct, but when I saw the size of the object, I > decided it would be quicker to use an ORM. > > The reason for Cayenne, is it creates good quality SQL joins that DBAs > dont go wild at. > > If the service layer is almost pure interface, then the implementor is not > bound and there is clean separation. (I am leaving all Enums in the > interface, just enough to stop it being a class). > > I agree with you on the AbstractGadgetData, although I can cope with that > one. > > I could probably work with pojos and , but I think I would have to resort > to GCLib.... which is nasty. > Ian > > > > > On 20 Apr 2008, at 18:15, Cassie wrote: > > > Well... interfaces seem a lot more complicated then just pojos. Why > > would a > > pojo need to be an interface to begin with? > > > > As for the AbstractGadgetData thing we really really need to get rid of > > that > > class, so that's a little bit of a separate issue. Ideally we would just > > use > > a java->json->java library which takes in any java object, and does not > > require inheritance. What we have right now is a very good stop gap > > solution. > > > > So why do you need to change the default pojo implementation of a pojo? > > Can > > you simply extend Person.java to do what you need? Any details would > > greatly > > help us all make a good design decision together. > > > > Thanks. > > > > - Cassie > > > > > > On Sun, Apr 20, 2008 at 4:39 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > > > > I guess this is really a question for Cassie.... > > > > > > How receptive would you be to extracting interfaces from the model > > > area to > > > enable other implementation schemes. > > > > > > eg > > > all the classes in org.apache.shindig.opensocial.model become > > > interfaces > > > the sample container provides an set of implementations bound to the > > > interfaces. > > > > > > AbstractGadgetData implements a GadgetData interface and that is used > > > where > > > AbstractGadgetData is used. > > > > > > I can provide a patch... > > > > > > > > > Ian > > > > > > > > > > > > > > > >
