Le 14/04/11 22:14, Ciancetta, Jesse E. a écrit :
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
Don't you think this will make things overly complex ?
Java developers (which I am) always try to have a maximum-flexibility /
no-adherence-to-any-framework approach that acually adds a lot of
overhead to the design.
Is it really a problem if POJOs have JPA annotations but are used in a
non-JPA context ?
Also, noSQL certainly has the hype, but is it *needed* for the kind of
objects that will be persisted, even with millions of users ? Is this
user accounts and their portal layout ? Can't a simple key partitioning
scheme solve the most extreme use cases ? Also, don't forget that most
IT departments don't like much these new noSQL beasts that their admin
staff know nothing about.
Don't get me wrong, I'm just trying to be pragmatic.
And if you really want to separate JPA annotations out of the model
POJOs, you should consider the rather interesting approach used by
Spring ROO [1] : the various concerns that contribute to a class are
separated in different AspectJ files, including javabean getters and
setters, JPA annotations, etc.
My 2 cents.
Sylvain
[1] http://www.springsource.org/roo
--
Sylvain Wallez - http://bluxte.net
