You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Franklin, Matthew B." <mf...@mitre.org> on 2011/04/13 17:53:57 UTC
Interface vs POJO for Model Objects
I envision model objects as simple containers for data, and IMO, making
them interfaces over-complicates their use within the system. Scott has
expressed that he prefers interfaces over POJOs, so this thread is
intended to discuss the issue and build the community's consensus.
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.
On the other hand, I am a big advocate of interfaces for services,
repositories and any other components that perform actions.
-Matt
Re: Something is better than nothing (was Re: Interface vs POJO for
Model Objects)
Posted by Ross Gardler <rg...@apache.org>.
On 15/04/2011 11:34, Ross Gardler wrote:
> +1
Just to be clear, I changed the subject so that my "+1" was referring to
Ate's lets "get something moving proposal" rather than to the interface
Vs models discussion.
I do have an opinion on the specific issue but since I won't be coding
on this any time soon I'm not going to express it. Both approaches seem
to be perfectly sensible at this point in time.
Ross
Something is better than nothing (was Re: Interface vs POJO for Model
Objects)
Posted by Ross Gardler <rg...@apache.org>.
On 15/04/2011 01:26, Ate Douma wrote:
> 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.
+1
In cases like this (Interface Vs POJO)where there are two well reasoned
but conflicting sets of opinions it's probably best to just get on with it.
The problem is how to pick which route to "get on with".
The key deciding factor (at least for me) is which will get us to the
point of having something to show the "customer" the quickest without
closing off the alternative route entirely.
> 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.
+1
The key here is the door is always open for someone to make a case for
the customer needing (as opposed to "possibly wanting") NoSQL.
Ross
Re: Interface vs POJO for Model Objects
Posted by Ate Douma <at...@douma.nu>.
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
>
Re: Interface vs POJO for Model Objects
Posted by Sylvain Wallez <sy...@apache.org>.
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
RE: Interface vs POJO for Model Objects
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>-----Original Message-----
>From: Woonsan Ko [mailto:woon_san@yahoo.com]
>Sent: Thursday, April 14, 2011 2:33 PM
>To: rave-dev@incubator.apache.org
>Subject: Re: Interface vs POJO for Model Objects
>
>
>--- On Wed, 4/13/11, Ross Gardler <rg...@apache.org> wrote:
>
>> From: Ross Gardler <rg...@apache.org>
>> Subject: Re: Interface vs POJO for Model Objects
>> To: rave-dev@incubator.apache.org
>> 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
>>
Re: Interface vs POJO for Model Objects
Posted by Woonsan Ko <wo...@yahoo.com>.
--- On Wed, 4/13/11, Ross Gardler <rg...@apache.org> wrote:
> From: Ross Gardler <rg...@apache.org>
> Subject: Re: Interface vs POJO for Model Objects
> To: rave-dev@incubator.apache.org
> 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.
>
> 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
>
Re: Interface vs POJO for Model Objects
Posted by Ross Gardler <rg...@apache.org>.
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
Re: Interface vs POJO for Model Objects
Posted by Scott Wilson <sc...@gmail.com>.
On 13 Apr 2011, at 16:53, Franklin, Matthew B. wrote:
> I envision model objects as simple containers for data, and IMO, making
> them interfaces over-complicates their use within the system. Scott has
> expressed that he prefers interfaces over POJOs, so this thread is
> intended to discuss the issue and build the community's consensus.
Thanks Matt,
>
> 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.
>
> On the other hand, I am a big advocate of interfaces for services,
> repositories and any other components that perform actions.
>
> -Matt
>