On 04/14/2011 11:12 PM, Sylvain Wallez wrote:
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 ?
It probably will make things more complex, but we'll probably will have to deal
with interface based features (e.g. services and otherwise "pluggable"
components) anyway.
Will it become overly complex?
Well, I think it is our duty to not make it so. If it happens, its our own
doing, not by definition or just because of using interfaces itself.
That doesn't mean I'm strongly advocating using interfaces right now.
I think we really should start simple and get something to "play" with ASAP.
As long as we're still in the "prototyping" phase (which I think we'll be in for
a while), I really don't care a lot about too strong upfront design principals.
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.
True, but I've encountered the opposite effect too often as well.
As long as one needs to build a solution for just a single purpose/goal,
spending too much time on "grand design" really is overkill, which might kill
you (or your project) indeed.
But if you need to build something which is upfront expected to be extended and
integrated in (especially enterprise level) external system/environments, not
catering for at least some reusable and extendable design can easily make your
solution obsolete or irrelevant before its finished...
IMO, Rave does target the latter, as actually are many/most ASF (middleware
oriented) projects. And sure enough, providing interface based and driven
solutions is very much applied at those ASF projects.
So, in the end, I expect we'll have to cater for more than just one
back-end/persistence layer.
To be completely clear: I already know that for a fact :)
But JPA will do fine as default and out-of-the-box solution for Rave, and
should, at this stage, get first priority.
Is it really a problem if POJOs have JPA annotations but are used in a non-JPA
context ?
If those other non-JPA contexts also require/desire annotations then yes it
might become quirky. And it certainly will if they cannot use it...
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 ?
It will be much more than just user accounts and portal layout.
Every user (which could end up being millions) might need persistence for
widget/gadget and/or page/layout bounded preferences or app data.
Especially the user preferences/app data I expect will quickly demand a noSQL if
you're going to scale up into the millions of users.
Unless someone knows how to "bind" JPA (generically) to noSQL backends.
Which actually might be an interesting idea to consider...
FYI: at Hippo we use JDO (Datanucleus) to provide ORM over JCR...
Not the same thing, and JDO is a much better spec than JPA in this regard, but
it also seems to have lost the battle against JPA.
Also, don't forget that most IT departments don't like much
these new noSQL beasts that their admin staff know nothing about.
That might depend on how strong they *need* noSQL when scalability problems
starts making their system unreliable or unmanageable.
And when they start moving to (true) cloud based storage, those complains become
irrelevant anyway.
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.
Well, Spring ROO might be great but also out of our reach to use at ASF (GPL3).
My 2 cents.
Thanks Sylvain.
Please also don't get me wrong. I very much appreciate your very sensible
questions and comments.
I certainly also want us to keep a pragmatic view and not get lost in
over-designed solutions.
So, I'm +1 to start with just JPA annotated POJOs, but keep an open mind for
possible other persistence back-end integration and make sure that will remain
doable. If that ends up requiring refactor to interfaces later, fine too.
Ate
Sylvain
[1] http://www.springsource.org/roo
