--- On Wed, 4/13/11, Ross Gardler <[email protected]> wrote: > From: Ross Gardler <[email protected]> > Subject: Re: Interface vs POJO for Model Objects > To: [email protected] > Date: Wednesday, April 13, 2011, 10:42 PM > On 13/04/2011 18:56, Scott Wilson > wrote: > > On 13 Apr 2011, at 16:53, Franklin, Matthew B. wrote: > > ... > > >> To clarify my thinking I present the following > example pseudo code > >> to demonstrate my preferred pattern: > >> > >> class Widget { String Title; String Author; ... > >> > >> //getters& setters } > >> > >> A Widget object is both retrieved from the > persistence layer and > >> created from data posted by the client. > Coming from the client, > >> the creation of a Widget instance is obvious and > simple with the > >> above approach. If we were to have a Widget > interface defining the > >> same getters& setters, object creation > becomes more difficult, as > >> you need a factory (or some other method of > instantiation) to > >> control what implementation gets created. > > > > I think if its a case of interfaces vs POJOs then I > also favour POJOs > > (I also write a lot of Rails code...) > > > > However, in Java server applications we rarely have > POJOs, but > > instead have heavily instrumented classes that > interact with the > > persistence mechanisms and other framework artefacts. > > > > So a POJO is encumbered with JPA instrumentation such > as annotations, > > queries, table references and so on. We may as well > call these > > "JPAJOs" rather than "POJOs" > > > > This instrumentation also makes it harder to > understand the role of > > the class as part of the domain model of the > application. You have to > > "see through" the thick layer of stuff obscuring the > model. > > Interfaces are one way of doing this. > > > > If we add another persistence framework - e.g. JCR or > NoSQL - then > > the "JPAJO" has to be recreated with new > instrumentation, and we have > > to use interfaces and factories anyway. (We've already > discussed here > > how JPA is our number one choice but there is a lot of > interest in > > supporting other store types.) So going with "JPAJOs" > without > > interfaces may not bring much simplicity for very > long. > > > > So that's my thinking here.
I totally agree with Scott. > > How likely are we to implement another persistence > framework? "Pluggable > persistence " appears in the "extensible features" of our > proposal (i.e. > it's part of the initial feature list). Is JPA sufficient > to satisfy > that feature? Personally, I would like to help with JCR or CMIS persistence later. I'm interested in integrating Rave Widgets with WCMS and its web application development toolkits. JPA only wouldn't work nicely. There are plenty of OCM solutions: Jackrabbit-OCM, JCROM, ... I don't think it would be nice to force to use JPA api for other persistences. > > We have certainly discussed things like NoSQL, but is > anyone actually > planning on implementing that as a priority? I don't have a priority for that now, but I hope to have it in the near future. IMHO, we will end up with an optional NoSQL persistence support for huge websites which use NoSQL such as HBase, Cassandra or whatever. At least, I think we need to allow them to support those. Regards, Woonsan > > Are other persistence frameworks something that we need, or > are they > something that we'd like to play with? > > Would the refactoring required to make this happen at some > point in the > future be prohibitive? > > Is the case for Interfaces only about persistence > frameworks? > > Ross >
