Ah, okay, I understand now. *sigh* I guess we will need to do it, huh? Oh well, I suppose its only 2 classes vs 1, not too bad. I see your bug and will take a look at the patch soon.
- Cassie On Sun, Apr 20, 2008 at 7:54 PM, 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 >>> >>> >>> >>> > >
