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.
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?
We have certainly discussed things like NoSQL, but is anyone actually planning on implementing that as a priority?
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
