>-----Original Message----- >From: Woonsan Ko [mailto:[email protected]] >Sent: Thursday, April 14, 2011 2:33 PM >To: [email protected] >Subject: Re: Interface vs POJO for Model Objects > > >--- 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.
Yeah -- I think I'm tending to agree with Scott here now too. I knew that going with JPA for a default implementation meant that our POJO model objects really become something more along the lines of the JPAJO's that Scott describes, but I was thinking that as long as we were careful to treat them as POJO's in our use throughout the application that the annotations would be irrelevant and they'd still just be POJO's. And I still that that actually holds true, but I hadn't considered the possibility for annotation overload which could definitely be problematic. I also care a lot about being able to swap out our persistence layer for a different type of store at some point in the future, because as Woonsan points out below I think that will be a real requirement for huge volume websites. So I guess at this point I'm: +1 for interfaces over the models >> >> 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 >>
