There are other issues with this approach as well. Namely, that you would need to create deep copies of the model objects passed into save or other persistence methods. I am going to stick with the JPAPOJO for now and we can explore other approaches as they come up.
-Matt On 4/19/11 9:44 AM, "Raminderjeet Singh" <[email protected]> wrote: >I saw the same thing being done by Jesse in his commit yesterday. I >personally feel that makes JPA layer more difficult and more error-prone >also. Any add/removal of element in Model will need change all the JPA >classes where model is used. I may not have understood your idea >completely. I would like to see the code before making further comments. > >Thanks >Raminder >On Apr 19, 2011, at 8:19 AM, Franklin, Matthew B. wrote: > >> I was thinking a bit about the model objects as interfaces vs POJO vs >> JPAPOJO and thought of a slightly different approach. What if we keep >>the >> model objects as POJOs and allow the persistence layer to create their >>own >> model objects that extend the Rave model and decorate them according to >> their own persistence strategy? Since we (I think) all plan on treating >> the Rave model objects as POJOs, regardless of their underlying nature, >> this approach may serve everyone's needs. >> >> Unless there are objections, I am going to replace Jesse's mock >> persistence layer with a JPA layer that hits an in-memory database and >> uses the strategy outlined above. >> >> -Matt >> >
