Re: [OT] RE: Persistence Framework Comparison?

[Eddie Bush]

Joe Barefoot wrote:

>Yes, but it doesn't use it "..under the covers" in any way, the implications of that 
>are quite different.  OJB uses torque as a tool, just as another client application 
>would.  It is in no way dependent on torque for its core functionality.
>
^^ That's what I was getting at ^^

>Does Tomcat uses Xerces "under the covers" when it uses it to parse configuration 
>files?
>
>peace,
>Joe
>
Peace :-)

-- 
Eddie Bush




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [OT] RE: Persistence Framework Comparison?

[Joe Barefoot]

Yes, but it doesn't use it "..under the covers" in any way, the implications of that 
are quite different.  OJB uses torque as a tool, just as another client application 
would.  It is in no way dependent on torque for its core functionality.

Does Tomcat uses Xerces "under the covers" when it uses it to parse configuration 
files?

peace,
Joe

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 7:17 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [OT] RE: Persistence Framework Comparison?
> 
> 
> Regardless, it uses torque.
> 
> 
> >From: "Joe Barefoot" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" 
> <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Subject: RE: [OT] RE: Persistence Framework Comparison?
> >Date: Fri, 4 Oct 2002 16:55:37 -0700
> >
> >No, it doesn't, not for any of the persistence mechanisms or runtime 
> >operations at least.  The only thing that OJB uses Torque 
> for is generating 
> >a database schema from an XML mapping file.  Everthing else 
> is built from 
> >the ground up.  It's very likely that Turbine will replace 
> Torque with OJB 
> >at some point in the future, according to one of the OJB 
> developers 'round 
> >here.
> >
> >peace,
> >Joe
> >
> > > -Original Message-
> > > From: David Graham [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, October 04, 2002 4:46 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: [OT] RE: Persistence Framework Comparison?
> > >
> > >
> > > It did come up briefly.  The Jakarta OJB project uses Torque
> > > under the
> > > covers as well.
> > >
> > > Dave
> > >
> > >
> > > >From: [EMAIL PROTECTED]
> > > >Reply-To: "Struts Users Mailing List"
> > > <[EMAIL PROTECTED]>
> > > >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > > >Subject: RE: Persistence Framework Comparison?
> > > >Date: Fri, 4 Oct 2002 19:42:34 -0400
> > > >
> > > >
> > > >
> > > >
> > > >btw -
> > > >
> > > >Given all this talk about DAO's etc, I'm wondering why the
> > > Torque work from
> > > >the Jakarta Turbine
> > > >project isn't coming up. It's very cool and worth checking
> > > out. I've seen
> > > >it used on production
> > > >apps and I know people like it.
> > > >
> > > >   http://jakarta.apache.org/turbine/torque/
> > > >
> > > >From the Torque site:
> > > >
> > > >   Torque is a persistence layer. Torque generates all
> > > the database
> > > >resources required
> > > >   by your application and includes a runtime
> > > environment to run the
> > > >generated classes.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >[EMAIL PROTECTED] on 10/04/2002 07:27:35 PM
> > > >
> > > >Please respond to "Struts Users Mailing List"
> > > ><[EMAIL PROTECTED]>
> > > >
> > > >To:"Struts Users Mailing List" 
> <[EMAIL PROTECTED]>
> > > >cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
> > > >Subject:RE: Persistence Framework Comparison?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > I've always thought of a DAO not as an Adapter pattern as
> > > what you are
> > > > > describing, but as an external Table Gateway.  BO
> > > interfaces and even
> > > > > the implementing classes shouldn't need to know how to
> > > persist itself or
> > > > > even what to persist to (XML, DB, IO).  That is up to the
> > > implementing
> > > > > Gateway.
> > > > >
> > > >
> > > >Adapter Pattern - I was trying to think of the name and
> > > couldn't. Thanks.
> > > >
> > > > > I think a DAO should just extend the functionality of 
> the business
> > > > > object, IE add configurable methods to persist, modify,
> > > select

RE: [OT] RE: Persistence Framework Comparison?

[David Graham]

Regardless, it uses torque.


>From: "Joe Barefoot" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: RE: [OT] RE: Persistence Framework Comparison?
>Date: Fri, 4 Oct 2002 16:55:37 -0700
>
>No, it doesn't, not for any of the persistence mechanisms or runtime 
>operations at least.  The only thing that OJB uses Torque for is generating 
>a database schema from an XML mapping file.  Everthing else is built from 
>the ground up.  It's very likely that Turbine will replace Torque with OJB 
>at some point in the future, according to one of the OJB developers 'round 
>here.
>
>peace,
>Joe
>
> > -Original Message-
> > From: David Graham [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, October 04, 2002 4:46 PM
> > To: [EMAIL PROTECTED]
> > Subject: [OT] RE: Persistence Framework Comparison?
> >
> >
> > It did come up briefly.  The Jakarta OJB project uses Torque
> > under the
> > covers as well.
> >
> > Dave
> >
> >
> > >From: [EMAIL PROTECTED]
> > >Reply-To: "Struts Users Mailing List"
> > <[EMAIL PROTECTED]>
> > >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> > >Subject: RE: Persistence Framework Comparison?
> > >Date: Fri, 4 Oct 2002 19:42:34 -0400
> > >
> > >
> > >
> > >
> > >btw -
> > >
> > >Given all this talk about DAO's etc, I'm wondering why the
> > Torque work from
> > >the Jakarta Turbine
> > >project isn't coming up. It's very cool and worth checking
> > out. I've seen
> > >it used on production
> > >apps and I know people like it.
> > >
> > >   http://jakarta.apache.org/turbine/torque/
> > >
> > >From the Torque site:
> > >
> > >   Torque is a persistence layer. Torque generates all
> > the database
> > >resources required
> > >   by your application and includes a runtime
> > environment to run the
> > >generated classes.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >[EMAIL PROTECTED] on 10/04/2002 07:27:35 PM
> > >
> > >Please respond to "Struts Users Mailing List"
> > ><[EMAIL PROTECTED]>
> > >
> > >To:"Struts Users Mailing List" <[EMAIL PROTECTED]>
> > >cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
> > >Subject:RE: Persistence Framework Comparison?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > I've always thought of a DAO not as an Adapter pattern as
> > what you are
> > > > describing, but as an external Table Gateway.  BO
> > interfaces and even
> > > > the implementing classes shouldn't need to know how to
> > persist itself or
> > > > even what to persist to (XML, DB, IO).  That is up to the
> > implementing
> > > > Gateway.
> > > >
> > >
> > >Adapter Pattern - I was trying to think of the name and
> > couldn't. Thanks.
> > >
> > > > I think a DAO should just extend the functionality of the business
> > > > object, IE add configurable methods to persist, modify,
> > select, etc and
> > > > leave the actual O/R logic up to the database with views,
> > triggers, and
> > > > stored procedures (I wrote a book on this last time
> > someone posted this
> > > > same topic).
> > > >
> > > > Here's how our open source DAO works:
> > > >
> > > > Action.execute(ActionForm loginForm)
> > > > {
> > > > DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
> > > > DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
> > > > Method login = daoBroker.createMethod("login",User.class);
> > > >
> > > > try
> > > > {
> > > > conn = dataSource.getConnection();
> > > > User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
> > > > if (actual == null) throw new LoginException();
> > > > }
> > > > finally
> > > > {
> > >  > SQL.close(conn);
> > > > }
> > > > }
> > >
> > >
> > >  Looks

Re: Persistence Framework Comparison?

[Matt Veitas]

I am sure that you have all heard one time or another about how certain 
persistence frameworks "rock"...

Hibernate is a simple and flexible framework.
http://hibernate.sourceforge.net

Matt



Joe Barefoot wrote:

>>-Original Message-
>>From: Robert J. Sanford, Jr. [mailto:[EMAIL PROTECTED]]
>>Sent: Friday, October 04, 2002 4:14 PM
>>To: Struts Users Mailing List
>>Subject: RE: Persistence Framework Comparison?
>>
>>
>>
>>
>>>>But, I cannot guarantee that the view I am reading from is 
>>>>updateable so I
>>>>
>>>>
>>>How can you not guarantee this if you are creating the data 
>>>model?  I don't understand.
>>>  
>>>
>>1 - I cannot guarantee the database that I will be using. Customer
>>requirements and all that other rot.
>>
>>
>
>Gotcha.
>
>  
>
>>2 - On one of my projects I currently have a logical object that
>>loads through a single view but requires an insert into multiple
>>tables to instantiate the logical object and I cannot do an
>>insert through the view.
>>
>>
>
>Better hope the customer choice of DB supports views at all then. :)
>
>  
>
>>3 - I'm not the DBA. I'm not qualified to be a DBA on anything but
>>simplistic projects and this is less than simplistic so I just
>>go with what I'm given. And sometimes the views are not able to
>>be updated.
>>
>>
>
>I think I'd talk some trash to the DBA then.  What, do they expect you to solve 
>everything, given the model?  I do appreciate your dilemma though, my condolences.
>
>  
>
>>rjsjr
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   
>><mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: 
>><mailto:[EMAIL PROTECTED]>
>>
>>
>>
>>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>  
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [OT] RE: Persistence Framework Comparison?

[Bryan Field-Elliot]

On Fri, 2002-10-04 at 15:28, David Graham wrote:

This is a layer above all persistence frameworks (JDBC, JDO, EJB, OJB,
etc.) 
that your application programs to.  If you decide to change persistence 
frameworks, most of your code remains unchanged because it doesn't know 
which one you're using.



I just don't think it's feasable to design a single, one-size-fits-all 
abstraction mechanism for all persistence layers. Many persistence
systems have different tricks and different emphases which defy any
attempt to neatly abstract them all.

For example the Simper framework (which I wrote) is designed to cut
through the MVC hierarchy like a butter knife, using the same beans in
the Model (which is Simper itself), to the Controller (Struts and your
actions), to the View (which is JSP, Velocity, etc). This is a FEATURE
not a shortcoming, to reduce data copying across layers and simplify
code management.

Other differences you may find are in the realm of code generation.
People tend to think that you're either writing beans by hand, or you're
having a tool auto-generate classes for you. But this is a false
assumption: Simper was designed to avoid code generation entirely. It's
all dynamic, using DynaBeans and what I call "point-and-shoot table
configuration". You don't write classes, you don't even auto-generate
classes. You just configure them, in a way similar to how Struts 1.1
lets you dynamically configure DynaActionForms.

In short, I think trying to make a single layer which sits above all
known persistence systems will just stifle creativity in approaches.

Bryan

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [OT] RE: Persistence Framework Comparison?

[Joe Barefoot]

No, it doesn't, not for any of the persistence mechanisms or runtime operations at 
least.  The only thing that OJB uses Torque for is generating a database schema from 
an XML mapping file.  Everthing else is built from the ground up.  It's very likely 
that Turbine will replace Torque with OJB at some point in the future, according to 
one of the OJB developers 'round here.

peace,
Joe

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 4:46 PM
> To: [EMAIL PROTECTED]
> Subject: [OT] RE: Persistence Framework Comparison?
> 
> 
> It did come up briefly.  The Jakarta OJB project uses Torque 
> under the 
> covers as well.
> 
> Dave
> 
> 
> >From: [EMAIL PROTECTED]
> >Reply-To: "Struts Users Mailing List" 
> <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Subject: RE: Persistence Framework Comparison?
> >Date: Fri, 4 Oct 2002 19:42:34 -0400
> >
> >
> >
> >
> >btw -
> >
> >Given all this talk about DAO's etc, I'm wondering why the 
> Torque work from
> >the Jakarta Turbine
> >project isn't coming up. It's very cool and worth checking 
> out. I've seen
> >it used on production
> >apps and I know people like it.
> >
> >   http://jakarta.apache.org/turbine/torque/
> >
> >From the Torque site:
> >
> >   Torque is a persistence layer. Torque generates all 
> the database 
> >resources required
> >   by your application and includes a runtime 
> environment to run the 
> >generated classes.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >[EMAIL PROTECTED] on 10/04/2002 07:27:35 PM
> >
> >Please respond to "Struts Users Mailing List"
> ><[EMAIL PROTECTED]>
> >
> >To:"Struts Users Mailing List" <[EMAIL PROTECTED]>
> >cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
> >Subject:RE: Persistence Framework Comparison?
> >
> >
> >
> >
> >
> >
> >
> >
> > > I've always thought of a DAO not as an Adapter pattern as 
> what you are
> > > describing, but as an external Table Gateway.  BO 
> interfaces and even
> > > the implementing classes shouldn't need to know how to 
> persist itself or
> > > even what to persist to (XML, DB, IO).  That is up to the 
> implementing
> > > Gateway.
> > >
> >
> >Adapter Pattern - I was trying to think of the name and 
> couldn't. Thanks.
> >
> > > I think a DAO should just extend the functionality of the business
> > > object, IE add configurable methods to persist, modify, 
> select, etc and
> > > leave the actual O/R logic up to the database with views, 
> triggers, and
> > > stored procedures (I wrote a book on this last time 
> someone posted this
> > > same topic).
> > >
> > > Here's how our open source DAO works:
> > >
> > > Action.execute(ActionForm loginForm)
> > > {
> > > DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
> > > DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
> > > Method login = daoBroker.createMethod("login",User.class);
> > >
> > > try
> > > {
> > > conn = dataSource.getConnection();
> > > User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
> > > if (actual == null) throw new LoginException();
> > > }
> > > finally
> > > {
> >  > SQL.close(conn);
> > > }
> > > }
> >
> >
> >  Looks very cool! Is this available somewhere?
> >
> >
> >  But back to my point - if you were to change over to using 
> an EJB server,
> >  the Action classes would have to change. This short Action 
> class isn't a
> >  big deal, but if you have long, complex forms that require multiple
> >updates
> >  then there can be an advantage to putting an "Adapter" in 
> front of the
> >  persistence logic.
> >
> >  The adapter can shorten long Action classes and make them easier to
> >  read and maintain. But on the other hand, I guess you do 
> have to create
> >  additional classes to use the adapter pattern, so it's a 
> trade off...
> >
> >  I think in the end, I prefer the approach that isolates 
> the Action class
> >  from having to know what kind of persistent store it is using.
> >
> >  T

RE: [OT]RE: Persistence Framework Comparison?

[Jacob Hookom]

| -Original Message-
| From: David Graham [mailto:[EMAIL PROTECTED]]
| Sent: Friday, October 04, 2002 6:39 PM
| To: [EMAIL PROTECTED]
| Subject: [OT]RE: Persistence Framework Comparison?
| 
| I'm concerned about the piece of your code that returns a Method
object.
| I
| assume this is the Method class from the reflection package.  It
doesn't
| strike me as a very good use of reflection and poor OO technique.  Of
| course, your code snippet doesn't show what you ultimately do with the
| Method object.

My implementation acts as a wrapper extending the functionality of an
object, you could say that it's the same as an Action in Struts.  Is
that poor programming? ;-)  Since you may add pre-compiled Methods via
the config, I chose this execution pattern to provide additional
flexibility in writing your own methods.  Plus I'm thinking of adding a
listener pattern to the methods to allow O/R mapping events to be passed
around the DaoBroker.

The User.class is being passed as the BO interface.  Dao's are stored in
a map under the class defined in the config.  So I may use
UserImpl.classs in the config, but if daos.get(User.class) returns null,
then it will search to see if the User.class is an interface of any Dao
and store an additional mapping for quick access next time.

| 
| Aspect oriented programming might suit your needs here and may be a
| cleaner
| design.  This isn't C where we pass around functions and execute them.
| 
| Dave

Jacob



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Craig R. McClanahan]

On Fri, 4 Oct 2002, Dan Cancro wrote:

> Date: Fri, 4 Oct 2002 15:53:42 -0700
> From: Dan Cancro <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: Persistence Framework Comparison?
>
> This made me think of a thought I had earlier.  Folks developed things like
> Velocity and XMLC because jsp has given people more than enough rope to hang
> themselves.  What if someone came up an analogous "Controller Template
> Language" that made it impossible to put business logic in your Action
> classes?  It would somehow use an interface like what is being described
> here to talk to the business/persistence parts.  I think that would be
> pretty cool.
>

You might want to take a look at the "jelly" project (in commons-sandbox)
for a way to deal with this kind of thing.  It's on my list of
technologies to evaluate for adding workflow support (post-Struts 1.1),
and it's much better (as well as farther along) than my original sandbox
project in that direction.

The basic thinking is that you'd script your Actions using Jelly, which
(among other things) can be made to call your business class methods
directly -- essentially you are just scripting an adapter between the web
tier and the business tier.  This doesn't make encoding business logic
impossible, but it's enough wordier that constructive laziness will
encourage the correct behavior :-).

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [OT] RE: Persistence Framework Comparison?

[Craig R. McClanahan]

On Fri, 4 Oct 2002, David Graham wrote:

> Date: Fri, 04 Oct 2002 17:44:14 -0600
> From: David Graham <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [OT] RE: Persistence Framework Comparison?
>
> Craig,
> It's good to see some MySQL bashing from a Sun guy :-).  I'm guessing you
> don't express that view too often working for the company that proclaimed
> "Unbreakable MySQL is the future".  No views, triggers, stored procedures,
> disdain for people who want views...what a joke.
>

Sometimes even big companies go along with things that are successful in
the market :-).

http://www.sun.com/servers/entry/lx50/

Sometimes people like me express our own personal opinions too :-).

> Dave

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Joe Barefoot]

> -Original Message-
> From: Robert J. Sanford, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 4:14 PM
> To: Struts Users Mailing List
> Subject: RE: Persistence Framework Comparison?
> 
> 
> > > But, I cannot guarantee that the view I am reading from is 
> > > updateable so I
> > 
> > How can you not guarantee this if you are creating the data 
> > model?  I don't understand.
> 
> 1 - I cannot guarantee the database that I will be using. Customer
> requirements and all that other rot.

Gotcha.

> 2 - On one of my projects I currently have a logical object that
> loads through a single view but requires an insert into multiple
> tables to instantiate the logical object and I cannot do an
> insert through the view.

Better hope the customer choice of DB supports views at all then. :)

> 3 - I'm not the DBA. I'm not qualified to be a DBA on anything but
> simplistic projects and this is less than simplistic so I just
> go with what I'm given. And sometimes the views are not able to
> be updated.

I think I'd talk some trash to the DBA then.  What, do they expect you to solve 
everything, given the model?  I do appreciate your dilemma though, my condolences.

> 
> rjsjr
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Jacob Hookom]

| > I've always thought of a DAO not as an Adapter pattern as what you
are
| > describing, but as an external Table Gateway.  BO interfaces and
even
| > the implementing classes shouldn't need to know how to persist
itself or
| > even what to persist to (XML, DB, IO).  That is up to the
implementing
| > Gateway.
| >
| 
| Adapter Pattern - I was trying to think of the name and couldn't.
Thanks.
| 
|  Looks very cool! Is this available somewhere?

http://www.hookom.net/dao/api
http://www.hookom.net/dao/dao.jar
http://www.hookom.net/dao/conf.zip

I only have the original stuff here, I've made some tweaks as we
implement on the project (a work still in progress).

| 
| 
|  But back to my point - if you were to change over to using an EJB
server,
|  the Action classes would have to change. This short Action class
isn't a
|  big deal, but if you have long, complex forms that require multiple
| updates
|  then there can be an advantage to putting an "Adapter" in front of
the
|  persistence logic.
| 
|  The adapter can shorten long Action classes and make them easier to
|  read and maintain. But on the other hand, I guess you do have to
create
|  additional classes to use the adapter pattern, so it's a trade off...

I completely agree, but that point on creating classes is a biggie.
That's why I like to opt for the Gateway that's configurable via xml.

| 
|  I think in the end, I prefer the approach that isolates the Action
class
|  from having to know what kind of persistent store it is using.
| 
|  This isn't to take away from the work you've done - it looks great.

Thanks

| 
|  Again, just my views for what they're worth -
| 
|  Kevin
| 

Jacob

| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|

--
| -
| This e-mail message (including attachments, if any) is intended for
the
| use
| of the individual or entity to which it is addressed and may contain
| information that is privileged, proprietary , confidential and exempt
from
| disclosure.  If you are not the intended recipient, you are notified
that
| any dissemination, distribution or copying of this communication is
| strictly prohibited.  If you have received this communication in
error,
| please notify the sender and erase this e-mail message immediately.
|

--
| -
| 
| 
| 
| --
| To unsubscribe, e-mail:   
| For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[OT] RE: Persistence Framework Comparison?

[David Graham]

It did come up briefly.  The Jakarta OJB project uses Torque under the 
covers as well.

Dave


>From: [EMAIL PROTECTED]
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: RE: Persistence Framework Comparison?
>Date: Fri, 4 Oct 2002 19:42:34 -0400
>
>
>
>
>btw -
>
>Given all this talk about DAO's etc, I'm wondering why the Torque work from
>the Jakarta Turbine
>project isn't coming up. It's very cool and worth checking out. I've seen
>it used on production
>apps and I know people like it.
>
>   http://jakarta.apache.org/turbine/torque/
>
>From the Torque site:
>
>   Torque is a persistence layer. Torque generates all the database 
>resources required
>   by your application and includes a runtime environment to run the 
>generated classes.
>
>
>
>
>
>
>
>
>
>[EMAIL PROTECTED] on 10/04/2002 07:27:35 PM
>
>Please respond to "Struts Users Mailing List"
><[EMAIL PROTECTED]>
>
>To:"Struts Users Mailing List" <[EMAIL PROTECTED]>
>cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
>Subject:RE: Persistence Framework Comparison?
>
>
>
>
>
>
>
>
> > I've always thought of a DAO not as an Adapter pattern as what you are
> > describing, but as an external Table Gateway.  BO interfaces and even
> > the implementing classes shouldn't need to know how to persist itself or
> > even what to persist to (XML, DB, IO).  That is up to the implementing
> > Gateway.
> >
>
>Adapter Pattern - I was trying to think of the name and couldn't. Thanks.
>
> > I think a DAO should just extend the functionality of the business
> > object, IE add configurable methods to persist, modify, select, etc and
> > leave the actual O/R logic up to the database with views, triggers, and
> > stored procedures (I wrote a book on this last time someone posted this
> > same topic).
> >
> > Here's how our open source DAO works:
> >
> > Action.execute(ActionForm loginForm)
> > {
> > DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
> > DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
> > Method login = daoBroker.createMethod("login",User.class);
> >
> > try
> > {
> > conn = dataSource.getConnection();
> > User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
> > if (actual == null) throw new LoginException();
> > }
> > finally
> > {
>  > SQL.close(conn);
> > }
> > }
>
>
>  Looks very cool! Is this available somewhere?
>
>
>  But back to my point - if you were to change over to using an EJB server,
>  the Action classes would have to change. This short Action class isn't a
>  big deal, but if you have long, complex forms that require multiple
>updates
>  then there can be an advantage to putting an "Adapter" in front of the
>  persistence logic.
>
>  The adapter can shorten long Action classes and make them easier to
>  read and maintain. But on the other hand, I guess you do have to create
>  additional classes to use the adapter pattern, so it's a trade off...
>
>  I think in the end, I prefer the approach that isolates the Action class
>  from having to know what kind of persistent store it is using.
>
>  This isn't to take away from the work you've done - it looks great.
>
>  Again, just my views for what they're worth -
>
>  Kevin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>---
>This e-mail message (including attachments, if any) is intended for the use
>of the individual or entity to which it is addressed and may contain
>information that is privileged, proprietary , confidential and exempt from
>disclosure.  If you are not the intended recipient, you are notified that
>any dissemination, distribution or copying of this communication is
>strictly prohibited.  If you have received this communication in error,
>please notify the sender and erase this e-mail message immediately.
>---
>
>
>
>--
>To unsubscribe, e-mail:   <
>mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <
>mailto:[EMAIL PROTECTED]>
>
>
>
>
>
>
>
>---
>This e-mail message (including attachments, if any) is intended for the use
>of the individ

Re: [OT]RE: Persistence Framework Comparison?

[Kevin . Bedell]

> I'm concerned about the piece of your code that returns a Method object.
I
> assume this is the Method class from the reflection package.  It doesn't
> strike me as a very good use of reflection and poor OO technique.  Of
> course, your code snippet doesn't show what you ultimately do with the
> Method object.
>
> Aspect oriented programming might suit your needs here and may be a
cleaner
> design.  This isn't C where we pass around functions and execute them.
>
> Dave

Were you looking at something from me? Nothing I'm talking about uses
reflection
or 'Method's... I must be confused Or confusing




---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[OT] RE: Persistence Framework Comparison?

[David Graham]

Craig,
It's good to see some MySQL bashing from a Sun guy :-).  I'm guessing you 
don't express that view too often working for the company that proclaimed 
"Unbreakable MySQL is the future".  No views, triggers, stored procedures, 
disdain for people who want views...what a joke.

Dave


>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>Subject: RE: Persistence Framework Comparison?
>Date: Fri, 4 Oct 2002 15:18:50 -0700 (PDT)
>
>
>
>On Fri, 4 Oct 2002, Joe Barefoot wrote:
>
> > Date: Fri, 4 Oct 2002 15:00:04 -0700
> > From: Joe Barefoot <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > Subject: RE: Persistence Framework Comparison?
> >
> > > -Original Message-
> > > From: Robert J. Sanford, Jr. [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, October 04, 2002 3:00 PM
> > > To: Struts Users Mailing List
> > > Subject: RE: Persistence Framework Comparison?
> > >
> > >
> > > There are two things that I want/need in a persistence
> > > framework and I have
> > > yet to find them. I know that OJB does not support them and I have not
> > > looked very hard at the others. Maybe you can tell me if your product
> > > handles them.
> > >
> > > 1) Read only attributes so that a setter method is not automatically
> > > generated for one and that value is never persisted, just read.
> >
> > So delete the setter(s) you don't want from your entity objects.  Or
> > just make them empty methods that don't actually do anything.
> >
>
>You mean cut them out of the generated source code manually?  Every time
>you add a new column and regenerate?  Yuck ...
>
> > >
> > > 2) The ability to persist an object to a different "table"
> > > than it was read
> > > from. Yes this seems odd so let me explain in a few simple
> > > words followed by
> > > a simplistic example. The simple words are - performance and
> > > simplicity.
> > > When developing a web app database I tend to go for normalization. The
> > > employees are in one table with a FK to the department table.
> > > But, when
> > > displaying the data on a page I want to display the name of
> > > the department,
> > > not its database ID. So, I use a view that joins the two
> > > tables meaning that
> > >a) I get all the data that I need in a single query I can
> > >   get all of the information I need for display (performance)
> > >   and...
> > >b) I don't have to worry about reading data from multiple
> > >   queries and/or multiple objects (simplicity).
> > >
> > > But, I cannot guarantee that the view I am reading from is
> > > updateable so I
> >
> >
> > How can you not guarantee this if you are creating the data model?  I
> > don't understand.
> >
>
>Not all databases let you update through a view, even if the data model
>would otherwise allow it.  (Of course, there are even "databases" like
>MySQL that don't have views at all, but I digress :-).
>
>Craig
>
>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>




_
Chat with friends online, try MSN Messenger: http://messenger.msn.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Kevin . Bedell]

btw -

Given all this talk about DAO's etc, I'm wondering why the Torque work from
the Jakarta Turbine
project isn't coming up. It's very cool and worth checking out. I've seen
it used on production
apps and I know people like it.

  http://jakarta.apache.org/turbine/torque/

>From the Torque site:

  Torque is a persistence layer. Torque generates all the database resources 
required
  by your application and includes a runtime environment to run the generated 
classes.









[EMAIL PROTECTED] on 10/04/2002 07:27:35 PM

Please respond to "Struts Users Mailing List"
   <[EMAIL PROTECTED]>

To:"Struts Users Mailing List" <[EMAIL PROTECTED]>
cc:     (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject:RE: Persistence Framework Comparison?








> I've always thought of a DAO not as an Adapter pattern as what you are
> describing, but as an external Table Gateway.  BO interfaces and even
> the implementing classes shouldn't need to know how to persist itself or
> even what to persist to (XML, DB, IO).  That is up to the implementing
> Gateway.
>

Adapter Pattern - I was trying to think of the name and couldn't. Thanks.

> I think a DAO should just extend the functionality of the business
> object, IE add configurable methods to persist, modify, select, etc and
> leave the actual O/R logic up to the database with views, triggers, and
> stored procedures (I wrote a book on this last time someone posted this
> same topic).
>
> Here's how our open source DAO works:
>
> Action.execute(ActionForm loginForm)
> {
> DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
> DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
> Method login = daoBroker.createMethod("login",User.class);
>
> try
> {
> conn = dataSource.getConnection();
> User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
> if (actual == null) throw new LoginException();
> }
> finally
> {
 > SQL.close(conn);
> }
> }


 Looks very cool! Is this available somewhere?


 But back to my point - if you were to change over to using an EJB server,
 the Action classes would have to change. This short Action class isn't a
 big deal, but if you have long, complex forms that require multiple
updates
 then there can be an advantage to putting an "Adapter" in front of the
 persistence logic.

 The adapter can shorten long Action classes and make them easier to
 read and maintain. But on the other hand, I guess you do have to create
 additional classes to use the adapter pattern, so it's a trade off...

 I think in the end, I prefer the approach that isolates the Action class
 from having to know what kind of persistent store it is using.

 This isn't to take away from the work you've done - it looks great.

 Again, just my views for what they're worth -

 Kevin















---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   <
mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <
mailto:[EMAIL PROTECTED]>







---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[OT]RE: Persistence Framework Comparison?

[David Graham]

I'm concerned about the piece of your code that returns a Method object.  I 
assume this is the Method class from the reflection package.  It doesn't 
strike me as a very good use of reflection and poor OO technique.  Of 
course, your code snippet doesn't show what you ultimately do with the 
Method object.

Aspect oriented programming might suit your needs here and may be a cleaner 
design.  This isn't C where we pass around functions and execute them.

Dave


>From: [EMAIL PROTECTED]
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: RE: Persistence Framework Comparison?
>Date: Fri, 4 Oct 2002 19:27:35 -0400
>
>
>
>
>
>
>
> > I've always thought of a DAO not as an Adapter pattern as what you are
> > describing, but as an external Table Gateway.  BO interfaces and even
> > the implementing classes shouldn't need to know how to persist itself or
> > even what to persist to (XML, DB, IO).  That is up to the implementing
> > Gateway.
> >
>
>Adapter Pattern - I was trying to think of the name and couldn't. Thanks.
>
> > I think a DAO should just extend the functionality of the business
> > object, IE add configurable methods to persist, modify, select, etc and
> > leave the actual O/R logic up to the database with views, triggers, and
> > stored procedures (I wrote a book on this last time someone posted this
> > same topic).
> >
> > Here's how our open source DAO works:
> >
> > Action.execute(ActionForm loginForm)
> > {
> > DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
> > DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
> > Method login = daoBroker.createMethod("login",User.class);
> >
> > try
> > {
> > conn = dataSource.getConnection();
> > User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
> > if (actual == null) throw new LoginException();
> > }
> > finally
> > {
>  > SQL.close(conn);
> > }
> > }
>
>
>  Looks very cool! Is this available somewhere?
>
>
>  But back to my point - if you were to change over to using an EJB server,
>  the Action classes would have to change. This short Action class isn't a
>  big deal, but if you have long, complex forms that require multiple
>updates
>  then there can be an advantage to putting an "Adapter" in front of the
>  persistence logic.
>
>  The adapter can shorten long Action classes and make them easier to
>  read and maintain. But on the other hand, I guess you do have to create
>  additional classes to use the adapter pattern, so it's a trade off...
>
>  I think in the end, I prefer the approach that isolates the Action class
>  from having to know what kind of persistent store it is using.
>
>  This isn't to take away from the work you've done - it looks great.
>
>  Again, just my views for what they're worth -
>
>  Kevin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>---
>This e-mail message (including attachments, if any) is intended for the use
>of the individual or entity to which it is addressed and may contain
>information that is privileged, proprietary , confidential and exempt from
>disclosure.  If you are not the intended recipient, you are notified that
>any dissemination, distribution or copying of this communication is
>strictly prohibited.  If you have received this communication in error,
>please notify the sender and erase this e-mail message immediately.
>---
>
>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>




_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [OT] RE: Persistence Framework Comparison?

[David Graham]

I think we're talking about the same thing.  Whatever you want to call it 
(DAO, persistence layer, mappers) it still accomplishes the same thing.  
Only your daos would know about JDO or JDBC so yes, the change is located in 
one place.

All I'm suggesting is that a dao helper framework is useful for implementing 
your dao classes.  I've called mine "mappers" because they're used to map 
objects to a datastore and I think it reads better than an abbreviation like 
DAO; however, it's obvious that dao is more widely and immediately 
understood.

My framework includes a JdbcMapper parent class for all mappers using JDBC 
as their persistence technology.  This class reduces the amount of mundane 
jdbc code I need to write; if I would just learn JDO I could cut it down 
even more ;-).

Dave


>From: "James Higginbotham" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: RE: [OT] RE: Persistence Framework Comparison?
>Date: Fri, 4 Oct 2002 17:10:23 -0500
>
>
>
> > -Original Message-
> > From: David Graham [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, October 04, 2002 4:29 PM
> > To: [EMAIL PROTECTED]
> > Subject: [OT] RE: Persistence Framework Comparison?
> >
> >
> > I think you missed the point.  Yes, JDO lets you program to
> > an interface
> > with multiple vendors competing on implementations.  But what
> > if you don't
> > want to use JDO?
>
>Hmm... Ok, understood - I guess it depends on how far your project
>requires you to abstract from an O/R layer. I know things happen, but
>man.. If you are using JDO and want to abstract from an abstraction,
>where does it end? Anywho, I'm sure there are business or technical
>requirements for this, or its primarily for risk mitigation. I'm not on
>your project, so I have no say here ;)
>
> >
> > This is a layer above all persistence frameworks (JDBC, JDO,
> > EJB, OJB, etc.)
> > that your application programs to.  If you decide to change
> > persistence
> > frameworks, most of your code remains unchanged because it
> > doesn't know
> > which one you're using.
>
>Most of your code shouldn't care, only your DAOs, so the impact should
>only be on the data access layer you provide for your models. That
>shouldn't be a bad issue, since swapping out persistence frameworks
>usually isn't hard but there are nuiances to every one.
>
> >
> > I, and others, have rolled our own but I think it would be useful for
> > Jakarta Commons to provide this framework (similar to their
> > logging api).
>
>Maybe you should consider pitching it to Apache Commons or open it up on
>Sourceforge and see if Apache or someone larger can manage it long term?
>
>Anyway, hope the abstraction works out for you on this.
>James
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>




_
Send and receive Hotmail on your mobile device: http://mobile.msn.com


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Kevin . Bedell]

> I've always thought of a DAO not as an Adapter pattern as what you are
> describing, but as an external Table Gateway.  BO interfaces and even
> the implementing classes shouldn't need to know how to persist itself or
> even what to persist to (XML, DB, IO).  That is up to the implementing
> Gateway.
>

Adapter Pattern - I was trying to think of the name and couldn't. Thanks.

> I think a DAO should just extend the functionality of the business
> object, IE add configurable methods to persist, modify, select, etc and
> leave the actual O/R logic up to the database with views, triggers, and
> stored procedures (I wrote a book on this last time someone posted this
> same topic).
>
> Here's how our open source DAO works:
>
> Action.execute(ActionForm loginForm)
> {
> DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
> DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
> Method login = daoBroker.createMethod("login",User.class);
>
> try
> {
> conn = dataSource.getConnection();
> User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
> if (actual == null) throw new LoginException();
> }
> finally
> {
 > SQL.close(conn);
> }
> }


 Looks very cool! Is this available somewhere?


 But back to my point - if you were to change over to using an EJB server,
 the Action classes would have to change. This short Action class isn't a
 big deal, but if you have long, complex forms that require multiple
updates
 then there can be an advantage to putting an "Adapter" in front of the
 persistence logic.

 The adapter can shorten long Action classes and make them easier to
 read and maintain. But on the other hand, I guess you do have to create
 additional classes to use the adapter pattern, so it's a trade off...

 I think in the end, I prefer the approach that isolates the Action class
 from having to know what kind of persistent store it is using.

 This isn't to take away from the work you've done - it looks great.

 Again, just my views for what they're worth -

 Kevin















---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Persistence Framework Comparison?

[Jacob Hookom]

I wrote it one weekend to get ready for a project (packages are named
org.apache.persistent.*); I can send you the original code with a sample
Main if you are interested.  I wrote it such that I could donate it to
Jakarta possibly, but I'm not familiar with the procedures involved.

| -Original Message-
| From: news [mailto:[EMAIL PROTECTED]] On Behalf Of V. Cekvenich
| Sent: Friday, October 04, 2002 6:11 PM
| To: [EMAIL PROTECTED]
| Subject: Re: Persistence Framework Comparison?
| 
| Is it free? Where can I "download" this?
| Is there a sample?
| 
| .V
| 
| 
| Jacob Hookom wrote:
| > I've always thought of a DAO not as an Adapter pattern as what you
are
| > describing, but as an external Table Gateway.  BO interfaces and
even
| > the implementing classes shouldn't need to know how to persist
itself or
| > even what to persist to (XML, DB, IO).  That is up to the
implementing
| > Gateway.
| >
| > I think a DAO should just extend the functionality of the business
| > object, IE add configurable methods to persist, modify, select, etc
and
| > leave the actual O/R logic up to the database with views, triggers,
and
| > stored procedures (I wrote a book on this last time someone posted
this
| > same topic).
| >
| > Here's how our open source DAO works:
| >
| > Action.execute(ActionForm loginForm)
| > {
| > DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
| > DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
| > Method login = daoBroker.createMethod("login",User.class);
| >
| > try
| > {
| > conn = dataSource.getConnection();
| > User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
| > if (actual == null) throw new LoginException();
| > }
| > finally
| > {
| > SQL.close(conn);
| > }
| > }
| >
| > The config for this DAO looks like:
| >
| > 
| >
| >
| >
| >   
| >  select * from tbl_user where email = ? and password = ?
| >   
| >   
| >  
| >  
| >   
| >
| > 
| >
| > CRUD methods are automatically created at config time based on field
| > definitions.  It works great and the BO's are just left as retainers
of
| > state.  If you need specialized operations like a persist only
fields
| > that are changed, then the  can take in a class of type
Method.
| >
| >
| > | -Original Message-
| > | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| > | Sent: Friday, October 04, 2002 5:33 PM
| > | To: Struts Users Mailing List
| > | Subject: Re: Persistence Framework Comparison?
| > |
| > |
| > |
| > |
| > |
| > |
| > | >My wish was for a persistence or a ADO interface, and interface
only,
| > in
| > | >Jakarta or else where respected.
| > | >
| > | >If there were such an interface one could switch from JDO to ORB
to
| > OJB
| > | >to EJB to Simper to DAORowset to xyz, assuming other followed the
| > | >interface. Let them compete.
| > | >
| > | >Such interfaces would have to be very light weight. (Ex: find(),
| > save(),
| > | >commit(), getProperty(""); setProperty("", Object))
| > | >
| > |
| > |
| > | Asking for interfaces to be defined for ADO or a persistence layer
| > seems
| > | like asking for interface definitions for 'Model' components.
| > |
| > | I'd argue that the better approach is to create interfaces based
on
| > the
| > | business requirements of your specific project.
| > |
| > | For example, define an Interface for a customer record and call it
| > | 'Customer'. Then give it 'business methods' like
'getCustomerDetails'
| > or
| > | 'updateCustomerPhoneNumber'. Implement your Action class to act
ONLY
| > ON
| > | THE INTERFACE METHODS.
| > |
| > | Then build 'Model' components that implement the Interfaces. This
has
| > the
| > | effect of helping you keep code that is specific to a particular
| > | persistance layer OUT of the Action class. Then when you need to
| > switch
| > | persistence layers from JDBC to EJB (or to a web service or
whatever)
| > your
| > | ACTION CLASS CAN BE ALMOST COMPLETELY UNTOUCHED.
| > |
| > | For example:
| > |
| > |   Customer cust = new CustomerJDBCImpl();
| > |
| > |   cust.updatePhoneNumber('1-800-IMA-NERD');
| > |
| > | Where Customer is an interface and CustomerJDBCImpl is a class
that
| > | implements the Customer interface using a JDBC persistence layer.
| > |
| > | If you change persistence layers here, none of the code needs to
| > change
| > | in the Action class except you instantiate a different
implementation
| > | class. 

RE: Persistence Framework Comparison?

[Robert J. Sanford, Jr.]

> > But, I cannot guarantee that the view I am reading from is 
> > updateable so I
> 
> How can you not guarantee this if you are creating the data 
> model?  I don't understand.

1 - I cannot guarantee the database that I will be using. Customer
requirements and all that other rot.
2 - On one of my projects I currently have a logical object that
loads through a single view but requires an insert into multiple
tables to instantiate the logical object and I cannot do an
insert through the view.
3 - I'm not the DBA. I'm not qualified to be a DBA on anything but
simplistic projects and this is less than simplistic so I just
go with what I'm given. And sometimes the views are not able to
be updated.

rjsjr



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Persistence Framework Comparison?

[V. Cekvenich]

Is it free? Where can I "download" this?
Is there a sample?

.V


Jacob Hookom wrote:
> I've always thought of a DAO not as an Adapter pattern as what you are
> describing, but as an external Table Gateway.  BO interfaces and even
> the implementing classes shouldn't need to know how to persist itself or
> even what to persist to (XML, DB, IO).  That is up to the implementing
> Gateway.
> 
> I think a DAO should just extend the functionality of the business
> object, IE add configurable methods to persist, modify, select, etc and
> leave the actual O/R logic up to the database with views, triggers, and
> stored procedures (I wrote a book on this last time someone posted this
> same topic).
> 
> Here's how our open source DAO works:
> 
> Action.execute(ActionForm loginForm)
> {
> DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();
> DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
> Method login = daoBroker.createMethod("login",User.class);
> 
> try
> {
> conn = dataSource.getConnection();
> User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
> if (actual == null) throw new LoginException();
> }
> finally
> {
>   SQL.close(conn);
> }
> }
> 
> The config for this DAO looks like:
> 
> 
>
>
>
>   
>  select * from tbl_user where email = ? and password = ?
>   
>   
>  
>  
>   
>
> 
> 
> CRUD methods are automatically created at config time based on field
> definitions.  It works great and the BO's are just left as retainers of
> state.  If you need specialized operations like a persist only fields
> that are changed, then the  can take in a class of type Method.
> 
> 
> | -Original Message-
> | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> | Sent: Friday, October 04, 2002 5:33 PM
> | To: Struts Users Mailing List
> | Subject: Re: Persistence Framework Comparison?
> | 
> | 
> | 
> | 
> | 
> | 
> | >My wish was for a persistence or a ADO interface, and interface only,
> in
> | >Jakarta or else where respected.
> | >
> | >If there were such an interface one could switch from JDO to ORB to
> OJB
> | >to EJB to Simper to DAORowset to xyz, assuming other followed the
> | >interface. Let them compete.
> | >
> | >Such interfaces would have to be very light weight. (Ex: find(),
> save(),
> | >commit(), getProperty(""); setProperty("", Object))
> | >
> | 
> | 
> | Asking for interfaces to be defined for ADO or a persistence layer
> seems
> | like asking for interface definitions for 'Model' components.
> | 
> | I'd argue that the better approach is to create interfaces based on
> the
> | business requirements of your specific project.
> | 
> | For example, define an Interface for a customer record and call it
> | 'Customer'. Then give it 'business methods' like 'getCustomerDetails'
> or
> | 'updateCustomerPhoneNumber'. Implement your Action class to act ONLY
> ON
> | THE INTERFACE METHODS.
> | 
> | Then build 'Model' components that implement the Interfaces. This has
> the
> | effect of helping you keep code that is specific to a particular
> | persistance layer OUT of the Action class. Then when you need to
> switch
> | persistence layers from JDBC to EJB (or to a web service or whatever)
> your
> | ACTION CLASS CAN BE ALMOST COMPLETELY UNTOUCHED.
> | 
> | For example:
> | 
> |   Customer cust = new CustomerJDBCImpl();
> | 
> |   cust.updatePhoneNumber('1-800-IMA-NERD');
> | 
> | Where Customer is an interface and CustomerJDBCImpl is a class that
> | implements the Customer interface using a JDBC persistence layer.
> | 
> | If you change persistence layers here, none of the code needs to
> change
> | in the Action class except you instantiate a different implementation
> | class. Since the Action class operates on the Interface methods, it
> | doesn't care.
> | 
> | To summarize:
> | 
> |   - Leave persistence layer stuff out of Struts - it doesn't need
> it.
> |   - Define your 'Model' components using Interfaces for each
> project
> |   - Bury persistence layer stuff inside classes that implement
> | the interfaces.
> |   - Then, make all the changes to your persistence layer you want
> | and your Action classes (and form beans, etc) don't change.
> | 
> | This is the basic idea of MVC - seperate Model from View from
> Controller.
> | 
> | 
> | 
> | 

Re: Persistence Framework Comparison?

[Kevin . Bedell]

> Cool desgin!
>
> One comment is that ... it might be a bit harder to make it OO/reusable
> implementation. ("my" version has CRUD that uses reflection )
> With a "single" interface there could be more reuse.
>
> Curios, how do you do reuse?
>
> .V
>
>

Reuse? Hmm... I guess you don't reuse much at that level. You'd more likely
reuse things that were 'buried' in the implementation classes.

I don't think our approaches are really that much different - look at it
this way:

1. Define an interface for a project-specific Model component using
business methods (e.g., 'updatePhoneNumber').

2. Create a class that implements the interface and contains code that
actually updates the phone number using some 'persistence management' code.
This is where "your" code would be used.

I'm just proposing defining an interface that specifies how the Action
class (Controller) communicates with the persistence layer (Model). The
class that implements the interface may just provide a 'wrapper' to
reuseable classes that manage actually persisting the data.













But on the other hand, it saves time in maintenance of the stuff you've
already built -










---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Persistence Framework Comparison?

[Jacob Hookom]

I've always thought of a DAO not as an Adapter pattern as what you are
describing, but as an external Table Gateway.  BO interfaces and even
the implementing classes shouldn't need to know how to persist itself or
even what to persist to (XML, DB, IO).  That is up to the implementing
Gateway.

I think a DAO should just extend the functionality of the business
object, IE add configurable methods to persist, modify, select, etc and
leave the actual O/R logic up to the database with views, triggers, and
stored procedures (I wrote a book on this last time someone posted this
same topic).

Here's how our open source DAO works:

Action.execute(ActionForm loginForm)
{
DaoBrokerFactory dbf = DaoBrokerFactory.getInstance();  
DaoBroker daoBroker = dbf.createBroker("conf/dao-config.xml");
Method login = daoBroker.createMethod("login",User.class);

try
{
conn = dataSource.getConnection();
User actual = (User) daoBroker.selectSingle(loginForm,user,conn);
if (actual == null) throw new LoginException();
}
finally
{
SQL.close(conn);
}
}

The config for this DAO looks like:


   
   
   
  
 select * from tbl_user where email = ? and password = ?
  
  
 
 
  
   


CRUD methods are automatically created at config time based on field
definitions.  It works great and the BO's are just left as retainers of
state.  If you need specialized operations like a persist only fields
that are changed, then the  can take in a class of type Method.


| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Friday, October 04, 2002 5:33 PM
| To: Struts Users Mailing List
| Subject: Re: Persistence Framework Comparison?
| 
| 
| 
| 
| 
| 
| >My wish was for a persistence or a ADO interface, and interface only,
in
| >Jakarta or else where respected.
| >
| >If there were such an interface one could switch from JDO to ORB to
OJB
| >to EJB to Simper to DAORowset to xyz, assuming other followed the
| >interface. Let them compete.
| >
| >Such interfaces would have to be very light weight. (Ex: find(),
save(),
| >commit(), getProperty(""); setProperty("", Object))
| >
| 
| 
| Asking for interfaces to be defined for ADO or a persistence layer
seems
| like asking for interface definitions for 'Model' components.
| 
| I'd argue that the better approach is to create interfaces based on
the
| business requirements of your specific project.
| 
| For example, define an Interface for a customer record and call it
| 'Customer'. Then give it 'business methods' like 'getCustomerDetails'
or
| 'updateCustomerPhoneNumber'. Implement your Action class to act ONLY
ON
| THE INTERFACE METHODS.
| 
| Then build 'Model' components that implement the Interfaces. This has
the
| effect of helping you keep code that is specific to a particular
| persistance layer OUT of the Action class. Then when you need to
switch
| persistence layers from JDBC to EJB (or to a web service or whatever)
your
| ACTION CLASS CAN BE ALMOST COMPLETELY UNTOUCHED.
| 
| For example:
| 
|   Customer cust = new CustomerJDBCImpl();
| 
|   cust.updatePhoneNumber('1-800-IMA-NERD');
| 
| Where Customer is an interface and CustomerJDBCImpl is a class that
| implements the Customer interface using a JDBC persistence layer.
| 
| If you change persistence layers here, none of the code needs to
change
| in the Action class except you instantiate a different implementation
| class. Since the Action class operates on the Interface methods, it
| doesn't care.
| 
| To summarize:
| 
|   - Leave persistence layer stuff out of Struts - it doesn't need
it.
|   - Define your 'Model' components using Interfaces for each
project
|   - Bury persistence layer stuff inside classes that implement
| the interfaces.
|   - Then, make all the changes to your persistence layer you want
| and your Action classes (and form beans, etc) don't change.
| 
| This is the basic idea of MVC - seperate Model from View from
Controller.
| 
| 
| 
| I guess I think that one of the great strengths of Struts is ITS LACK
| OF TIGHT DEFINITIONS FOR MODEL COMPONENTS (DAO's, etc). This makes it
| flexible and allows you to define Model components based on the
'business
| rules' of the project - not based on what the framework recommends.
| 
| Just my thoughts, for what they're worth -
| 
| Kevin
| 
| 
| ---
| Kevin Bedell
| Author, "Struts Kickstart" - SAMS Publishing
| 
| 
| 
| 
| 
| >>>
| >>>Really?  I think Struts is quite good at what it does, and to me,
| >>>persistence seems to outside the scope of a web application MVC
| >>>framework.
| >>
| >>Agreed. Struts does what it does best - web MVC framework. What the
| >>

RE: Persistence Framework Comparison?

[Dan Cancro]

This made me think of a thought I had earlier.  Folks developed things like
Velocity and XMLC because jsp has given people more than enough rope to hang
themselves.  What if someone came up an analogous "Controller Template
Language" that made it impossible to put business logic in your Action
classes?  It would somehow use an interface like what is being described
here to talk to the business/persistence parts.  I think that would be
pretty cool.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 3:33 PM
> To: Struts Users Mailing List
> Subject: Re: Persistence Framework Comparison?
> 
> 
> 
> 
> 
> 
> 
> >My wish was for a persistence or a ADO interface, and 
> interface only, in
> >Jakarta or else where respected.
> >
> >If there were such an interface one could switch from JDO to 
> ORB to OJB
> >to EJB to Simper to DAORowset to xyz, assuming other followed the
> >interface. Let them compete.
> >
> >Such interfaces would have to be very light weight. (Ex: 
> find(), save(),
> >commit(), getProperty(""); setProperty("", Object))
> >
> 
> 
> Asking for interfaces to be defined for ADO or a persistence 
> layer seems
> like asking for interface definitions for 'Model' components.
> 
> I'd argue that the better approach is to create interfaces 
> based on the
> business requirements of your specific project.
> 
> For example, define an Interface for a customer record and call it
> 'Customer'. Then give it 'business methods' like 
> 'getCustomerDetails' or
> 'updateCustomerPhoneNumber'. Implement your Action class to 
> act ONLY ON
> THE INTERFACE METHODS.
> 
> Then build 'Model' components that implement the Interfaces. 
> This has the
> effect of helping you keep code that is specific to a particular
> persistance layer OUT of the Action class. Then when you need 
> to switch
> persistence layers from JDBC to EJB (or to a web service or 
> whatever) your
> ACTION CLASS CAN BE ALMOST COMPLETELY UNTOUCHED.
> 
> For example:
> 
>   Customer cust = new CustomerJDBCImpl();
> 
>   cust.updatePhoneNumber('1-800-IMA-NERD');
> 
> Where Customer is an interface and CustomerJDBCImpl is a class that
> implements the Customer interface using a JDBC persistence layer.
> 
> If you change persistence layers here, none of the code needs 
> to change
> in the Action class except you instantiate a different implementation
> class. Since the Action class operates on the Interface methods, it
> doesn't care.
> 
> To summarize:
> 
>   - Leave persistence layer stuff out of Struts - it 
> doesn't need it.
>   - Define your 'Model' components using Interfaces for 
> each project
>   - Bury persistence layer stuff inside classes that implement
> the interfaces.
>   - Then, make all the changes to your persistence layer you want
> and your Action classes (and form beans, etc) don't change.
> 
> This is the basic idea of MVC - seperate Model from View from 
> Controller.
> 
> 
> 
> I guess I think that one of the great strengths of Struts is ITS LACK
> OF TIGHT DEFINITIONS FOR MODEL COMPONENTS (DAO's, etc). This makes it
> flexible and allows you to define Model components based on 
> the 'business
> rules' of the project - not based on what the framework recommends.
> 
> Just my thoughts, for what they're worth -
> 
> Kevin
> 
> 
> ---
> Kevin Bedell
> Author, "Struts Kickstart" - SAMS Publishing
> 
> 
> 
> 
> 
> >>>
> >>>Really?  I think Struts is quite good at what it does, and to me,
> >>>persistence seems to outside the scope of a web application MVC
> >>>framework.
> >>
> >>Agreed. Struts does what it does best - web MVC framework. What the
> >>original author of the comments (sorry, lost in my mailbox 
> right now) is
> >>looking for is what I would recommend happen on top of 
> Struts. Something
> >>that takes Struts, a proven OSS O/R framework, and some glue to make
> >>DB-driven Struts applications faster to develop.
> >>
> 
> 
> 
> --
> -
> This e-mail message (including attachments, if any) is 
> intended for the use
> of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential 
> and exempt from
> disclosure.  If you are not the intended recipient, you are 
> notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication 
> in error,
> please notify the sender and erase this e-mail message immediately.
> --
> -
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Persistence Framework Comparison?

[V. Cekvenich]

Cool desgin!

One comment is that ... it might be a bit harder to make it OO/reusable 
implementation. ("my" version has CRUD that uses reflection )
With a "single" interface there could be more reuse.

Curios, how do you do reuse?

.V





[EMAIL PROTECTED] wrote:
> 
> 
> 
> 
>>My wish was for a persistence or a ADO interface, and interface only, in
>>Jakarta or else where respected.
>>
>>If there were such an interface one could switch from JDO to ORB to OJB
>>to EJB to Simper to DAORowset to xyz, assuming other followed the
>>interface. Let them compete.
>>
>>Such interfaces would have to be very light weight. (Ex: find(), save(),
>>commit(), getProperty(""); setProperty("", Object))
>>
> 
> 
> 
> Asking for interfaces to be defined for ADO or a persistence layer seems
> like asking for interface definitions for 'Model' components.
> 
> I'd argue that the better approach is to create interfaces based on the
> business requirements of your specific project.
> 
> For example, define an Interface for a customer record and call it
> 'Customer'. Then give it 'business methods' like 'getCustomerDetails' or
> 'updateCustomerPhoneNumber'. Implement your Action class to act ONLY ON
> THE INTERFACE METHODS.
> 
> Then build 'Model' components that implement the Interfaces. This has the
> effect of helping you keep code that is specific to a particular
> persistance layer OUT of the Action class. Then when you need to switch
> persistence layers from JDBC to EJB (or to a web service or whatever) your
> ACTION CLASS CAN BE ALMOST COMPLETELY UNTOUCHED.
> 
> For example:
> 
>   Customer cust = new CustomerJDBCImpl();
> 
>   cust.updatePhoneNumber('1-800-IMA-NERD');
> 
> Where Customer is an interface and CustomerJDBCImpl is a class that
> implements the Customer interface using a JDBC persistence layer.
> 
> If you change persistence layers here, none of the code needs to change
> in the Action class except you instantiate a different implementation
> class. Since the Action class operates on the Interface methods, it
> doesn't care.
> 
> To summarize:
> 
>   - Leave persistence layer stuff out of Struts - it doesn't need it.
>   - Define your 'Model' components using Interfaces for each project
>   - Bury persistence layer stuff inside classes that implement
> the interfaces.
>   - Then, make all the changes to your persistence layer you want
> and your Action classes (and form beans, etc) don't change.
> 
> This is the basic idea of MVC - seperate Model from View from Controller.
> 
> 
> 
> I guess I think that one of the great strengths of Struts is ITS LACK
> OF TIGHT DEFINITIONS FOR MODEL COMPONENTS (DAO's, etc). This makes it
> flexible and allows you to define Model components based on the 'business
> rules' of the project - not based on what the framework recommends.
> 
> Just my thoughts, for what they're worth -
> 
> Kevin
> 
> 
> ---
> Kevin Bedell
> Author, "Struts Kickstart" - SAMS Publishing
> 
> 
> 
> 
> 
> 
Really?  I think Struts is quite good at what it does, and to me,
persistence seems to outside the scope of a web application MVC
framework.
>>>
>>>Agreed. Struts does what it does best - web MVC framework. What the
>>>original author of the comments (sorry, lost in my mailbox right now) is
>>>looking for is what I would recommend happen on top of Struts. Something
>>>that takes Struts, a proven OSS O/R framework, and some glue to make
>>>DB-driven Struts applications faster to develop.
>>>
>>
> 
> 
> 
> ---
> This e-mail message (including attachments, if any) is intended for the use
> of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential and exempt from
> disclosure.  If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited.  If you have received this communication in error,
> please notify the sender and erase this e-mail message immediately.
> ---




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Persistence Framework Comparison?

[Kevin . Bedell]

>My wish was for a persistence or a ADO interface, and interface only, in
>Jakarta or else where respected.
>
>If there were such an interface one could switch from JDO to ORB to OJB
>to EJB to Simper to DAORowset to xyz, assuming other followed the
>interface. Let them compete.
>
>Such interfaces would have to be very light weight. (Ex: find(), save(),
>commit(), getProperty(""); setProperty("", Object))
>


Asking for interfaces to be defined for ADO or a persistence layer seems
like asking for interface definitions for 'Model' components.

I'd argue that the better approach is to create interfaces based on the
business requirements of your specific project.

For example, define an Interface for a customer record and call it
'Customer'. Then give it 'business methods' like 'getCustomerDetails' or
'updateCustomerPhoneNumber'. Implement your Action class to act ONLY ON
THE INTERFACE METHODS.

Then build 'Model' components that implement the Interfaces. This has the
effect of helping you keep code that is specific to a particular
persistance layer OUT of the Action class. Then when you need to switch
persistence layers from JDBC to EJB (or to a web service or whatever) your
ACTION CLASS CAN BE ALMOST COMPLETELY UNTOUCHED.

For example:

  Customer cust = new CustomerJDBCImpl();

  cust.updatePhoneNumber('1-800-IMA-NERD');

Where Customer is an interface and CustomerJDBCImpl is a class that
implements the Customer interface using a JDBC persistence layer.

If you change persistence layers here, none of the code needs to change
in the Action class except you instantiate a different implementation
class. Since the Action class operates on the Interface methods, it
doesn't care.

To summarize:

  - Leave persistence layer stuff out of Struts - it doesn't need it.
  - Define your 'Model' components using Interfaces for each project
  - Bury persistence layer stuff inside classes that implement
the interfaces.
  - Then, make all the changes to your persistence layer you want
and your Action classes (and form beans, etc) don't change.

This is the basic idea of MVC - seperate Model from View from Controller.



I guess I think that one of the great strengths of Struts is ITS LACK
OF TIGHT DEFINITIONS FOR MODEL COMPONENTS (DAO's, etc). This makes it
flexible and allows you to define Model components based on the 'business
rules' of the project - not based on what the framework recommends.

Just my thoughts, for what they're worth -

Kevin


---
Kevin Bedell
Author, "Struts Kickstart" - SAMS Publishing





>>>
>>>Really?  I think Struts is quite good at what it does, and to me,
>>>persistence seems to outside the scope of a web application MVC
>>>framework.
>>
>>Agreed. Struts does what it does best - web MVC framework. What the
>>original author of the comments (sorry, lost in my mailbox right now) is
>>looking for is what I would recommend happen on top of Struts. Something
>>that takes Struts, a proven OSS O/R framework, and some glue to make
>>DB-driven Struts applications faster to develop.
>>



---
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure.  If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Persistence Framework Comparison?

[Joe Barefoot]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 3:19 PM
> To: Struts Users Mailing List
> Subject: RE: Persistence Framework Comparison?
> 
> 
> 
> 
> On Fri, 4 Oct 2002, Joe Barefoot wrote:
> 
> > Date: Fri, 4 Oct 2002 15:00:04 -0700
> > From: Joe Barefoot <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > Subject: RE: Persistence Framework Comparison?
> >
> > > -Original Message-
> > > From: Robert J. Sanford, Jr. [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, October 04, 2002 3:00 PM
> > > To: Struts Users Mailing List
> > > Subject: RE: Persistence Framework Comparison?
> > >
> > >
> > > There are two things that I want/need in a persistence
> > > framework and I have
> > > yet to find them. I know that OJB does not support them 
> and I have not
> > > looked very hard at the others. Maybe you can tell me if 
> your product
> > > handles them.
> > >
> > > 1) Read only attributes so that a setter method is not 
> automatically
> > > generated for one and that value is never persisted, just read.
> >
> > So delete the setter(s) you don't want from your entity objects.  Or
> > just make them empty methods that don't actually do anything.
> >
> 
> You mean cut them out of the generated source code manually?  

yep

> Every time
> you add a new column and regenerate?  Yuck ...

Edit source code manually, oh horror of horrors :)  If your data model changes so 
frequently that this is an issue, I'd say you have bigger problems.  Agree that it 
would be nice to have this feature though.  Don't think that it's worth going with an 
otherwise inferior O/R framework just to have this feature however.

> 
> > >
> > > 2) The ability to persist an object to a different "table"
> > > than it was read
> > > from. Yes this seems odd so let me explain in a few simple
> > > words followed by
> > > a simplistic example. The simple words are - performance and
> > > simplicity.
> > > When developing a web app database I tend to go for 
> normalization. The
> > > employees are in one table with a FK to the department table.
> > > But, when
> > > displaying the data on a page I want to display the name of
> > > the department,
> > > not its database ID. So, I use a view that joins the two
> > > tables meaning that
> > >a) I get all the data that I need in a single query I can
> > >   get all of the information I need for display (performance)
> > >   and...
> > >b) I don't have to worry about reading data from multiple
> > >   queries and/or multiple objects (simplicity).
> > >
> > > But, I cannot guarantee that the view I am reading from is
> > > updateable so I
> >
> >
> > How can you not guarantee this if you are creating the data 
> model?  I
> > don't understand.
> >
> 
> Not all databases let you update through a view, even if the 
> data model

True.  I inferred it to mean that some of the views might be updateable, and others 
not, which didn't make sense to me.  

> would otherwise allow it.  (Of course, there are even "databases" like
> MySQL that don't have views at all, but I digress :-).

Boy, you really hate MySQL don't you?  ;P
> 
> Craig
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Craig R. McClanahan]

On Fri, 4 Oct 2002, Joe Barefoot wrote:

> Date: Fri, 4 Oct 2002 15:00:04 -0700
> From: Joe Barefoot <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Persistence Framework Comparison?
>
> > -Original Message-
> > From: Robert J. Sanford, Jr. [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, October 04, 2002 3:00 PM
> > To: Struts Users Mailing List
> > Subject: RE: Persistence Framework Comparison?
> >
> >
> > There are two things that I want/need in a persistence
> > framework and I have
> > yet to find them. I know that OJB does not support them and I have not
> > looked very hard at the others. Maybe you can tell me if your product
> > handles them.
> >
> > 1) Read only attributes so that a setter method is not automatically
> > generated for one and that value is never persisted, just read.
>
> So delete the setter(s) you don't want from your entity objects.  Or
> just make them empty methods that don't actually do anything.
>

You mean cut them out of the generated source code manually?  Every time
you add a new column and regenerate?  Yuck ...

> >
> > 2) The ability to persist an object to a different "table"
> > than it was read
> > from. Yes this seems odd so let me explain in a few simple
> > words followed by
> > a simplistic example. The simple words are - performance and
> > simplicity.
> > When developing a web app database I tend to go for normalization. The
> > employees are in one table with a FK to the department table.
> > But, when
> > displaying the data on a page I want to display the name of
> > the department,
> > not its database ID. So, I use a view that joins the two
> > tables meaning that
> >a) I get all the data that I need in a single query I can
> >   get all of the information I need for display (performance)
> >   and...
> >b) I don't have to worry about reading data from multiple
> >   queries and/or multiple objects (simplicity).
> >
> > But, I cannot guarantee that the view I am reading from is
> > updateable so I
>
>
> How can you not guarantee this if you are creating the data model?  I
> don't understand.
>

Not all databases let you update through a view, even if the data model
would otherwise allow it.  (Of course, there are even "databases" like
MySQL that don't have views at all, but I digress :-).

Craig



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: [OT] RE: Persistence Framework Comparison?

[James Higginbotham]

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, October 04, 2002 4:29 PM
> To: [EMAIL PROTECTED]
> Subject: [OT] RE: Persistence Framework Comparison?
> 
> 
> I think you missed the point.  Yes, JDO lets you program to 
> an interface 
> with multiple vendors competing on implementations.  But what 
> if you don't 
> want to use JDO?

Hmm... Ok, understood - I guess it depends on how far your project
requires you to abstract from an O/R layer. I know things happen, but
man.. If you are using JDO and want to abstract from an abstraction,
where does it end? Anywho, I'm sure there are business or technical
requirements for this, or its primarily for risk mitigation. I'm not on
your project, so I have no say here ;) 

> 
> This is a layer above all persistence frameworks (JDBC, JDO, 
> EJB, OJB, etc.) 
> that your application programs to.  If you decide to change 
> persistence 
> frameworks, most of your code remains unchanged because it 
> doesn't know 
> which one you're using.

Most of your code shouldn't care, only your DAOs, so the impact should
only be on the data access layer you provide for your models. That
shouldn't be a bad issue, since swapping out persistence frameworks
usually isn't hard but there are nuiances to every one.

> 
> I, and others, have rolled our own but I think it would be useful for 
> Jakarta Commons to provide this framework (similar to their 
> logging api).

Maybe you should consider pitching it to Apache Commons or open it up on
Sourceforge and see if Apache or someone larger can manage it long term?

Anyway, hope the abstraction works out for you on this. 
James

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [OT] RE: Persistence Framework Comparison?

[Craig R. McClanahan]

On Fri, 4 Oct 2002, David Graham wrote:

> Date: Fri, 04 Oct 2002 15:28:34 -0600
> From: David Graham <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [OT] RE: Persistence Framework Comparison?
>
> I think you missed the point.  Yes, JDO lets you program to an interface
> with multiple vendors competing on implementations.  But what if you don't
> want to use JDO?
>
> This is a layer above all persistence frameworks (JDBC, JDO, EJB, OJB, etc.)
> that your application programs to.  If you decide to change persistence
> frameworks, most of your code remains unchanged because it doesn't know
> which one you're using.
>
> I, and others, have rolled our own but I think it would be useful for
> Jakarta Commons to provide this framework (similar to their logging api).
>

On this general topic, there was talk a while back on
[EMAIL PROTECTED] about starting up a new top-level Apache
project (db.apache.org) to collect design patterns and implementations in
the general area of database access -- and this would certainly make an
appropriate home for something like a persistence layer interface.  Things
like commons-dbcp would probably end up migrating here as well.

Sadly, I don't think there's been any substantive progress on setting up
the infrastructure, yet.

> Dave

Craig


>
>
> >From: "James Higginbotham" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Subject: RE: Persistence Framework Comparison?
> >Date: Fri, 4 Oct 2002 16:18:10 -0500
> >
> >Oh, then what you are looking for is the ODMG API for object databases,
> >Sun's JDO (not Castor's JDO), or something similar. That is the purpose
> >of those 2 APIs at least, abstracting object storage frameworks.
> >
> >James
> >
> > > -Original Message-
> > > From: V. Cekvenich [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, October 04, 2002 4:03 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Persistence Framework Comparison?
> > >
> > >
> > > (Sorry, I can't read inline comments)
> > > "I'm curious why you think there would be any glue code needed?"
> > >
> > > It would not be Struts centric, agree. I have said to you Craig in
> > > person that I think one of the many reasons Struts was so
> > > successful is
> > > that it stayed above the persistence fey.
> > >
> > > My wish was for a persistence or a ADO interface, and
> > > interface only, in
> > > Jakarta or else where respected.
> > >
> > > When the person I responded to said words to the effect " it
> > > was painful
> > > to switch persistence frameworks" I said I wish there was an
> > > interface.
> > >
> > > If there were such an interface one could switch from JDO to
> > > ORB to OJB
> > > to EJB to Simper to DAORowset to xyz, assuming other followed the
> > > interface. Let them compete.
> > >
> > > Such interfaces would have to be very light weight. (Ex:
> > > find(), save(),
> > > commit(), getProperty(""); setProperty("", Object))
> > >
> > > It could be used by anyone, not just all beans! WebServices,
> > > JTable, etc.
> > >
> > > What it allows clients to do is make it easier to switch persistence
> > > layer that they outgrow or does not have good support, etc.
> > >
> > > Sort of like we say presentation layer should be replaceable
> > > and X:tag
> > > and Stxx lets you go PDF or else, same shold be on persistence. We
> > > should be able to switch.
> > >
> > > The glue is not one of my reasons at all. But it would make Struts
> > > examples better. (One Struts book out there has a getter
> > > property that
> > > accesses the db connection in the getter!! But that is
> > > not a Struts
> > > issue.)
> > >
> > > This is not just theory, my clients use a DAO interface I
> > > made up, that
> > > I can wrap around major persistence layers. The beans are
> > > isolated from
> > > how this happens, and it works.
> > > (this interfaces is public in a "good practices" sample Struts app,
> > > everyone knows were).
> > >
> > > hth,
> > > V.
> > >
> > >
> > >
> > >
> >

RE: Persistence Framework Comparison?

[Joe Barefoot]

> -Original Message-
> From: Robert J. Sanford, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 3:00 PM
> To: Struts Users Mailing List
> Subject: RE: Persistence Framework Comparison?
> 
> 
> There are two things that I want/need in a persistence 
> framework and I have
> yet to find them. I know that OJB does not support them and I have not
> looked very hard at the others. Maybe you can tell me if your product
> handles them.
> 
> 1) Read only attributes so that a setter method is not automatically
> generated for one and that value is never persisted, just read.

So delete the setter(s) you don't want from your entity objects.  Or just make them 
empty methods that don't actually do anything.

> 
> 2) The ability to persist an object to a different "table" 
> than it was read
> from. Yes this seems odd so let me explain in a few simple 
> words followed by
> a simplistic example. The simple words are - performance and 
> simplicity.
> When developing a web app database I tend to go for normalization. The
> employees are in one table with a FK to the department table. 
> But, when
> displaying the data on a page I want to display the name of 
> the department,
> not its database ID. So, I use a view that joins the two 
> tables meaning that
>a) I get all the data that I need in a single query I can
>   get all of the information I need for display (performance)
>   and...
>b) I don't have to worry about reading data from multiple
>   queries and/or multiple objects (simplicity).
> 
> But, I cannot guarantee that the view I am reading from is 
> updateable so I


How can you not guarantee this if you are creating the data model?  I don't understand.


> have to insert/update to the simple tables (employee for instance).
> 
> So, can you help me out here? Can your product do this?
> 
> rjsjr
> 
> > -----Original Message-----
> > From: Robert [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, October 04, 2002 4:12 PM
> > To: 'Struts Users Mailing List'
> > Subject: RE: Persistence Framework Comparison?
> >
> >
> > We have just released a free download for our eQ! software which you
> > might want to take a look at: www.browsersoft.com/eQ
> >
> > The demo app is built using Struts for the controller, JSTL 
> for taglibs,
> > our persistence layer and our XML scripting engine for 
> process logic.
> >
> > I'm the contact for it if you want more info.
> >
> > - Robert McIntosh
> > [EMAIL PROTECTED]
> >
> > -Original Message-
> > From: Karr, David [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, October 04, 2002 3:18 PM
> > To: 'Struts Users Mailing List'
> > Subject: RE: Persistence Framework Comparison?
> >
> > > -Original Message-
> > > From: James Higginbotham [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, October 04, 2002 1:12 PM
> > > To: Struts Users Mailing List
> > > Subject: RE: Persistence Framework Comparison?
> > >
> > >
> > > > >(I wish Struts had a non implemented persistance interface)
> > > >
> > > > Really?  I think Struts is quite good at what it does, 
> and to me,
> > > > persistence seems to outside the scope of a web application MVC
> > > > framework.
> > >
> > > Agreed. Struts does what it does best - web MVC 
> framework. What the
> > > original author of the comments (sorry, lost in my mailbox
> > > right now) is
> > > looking for is what I would recommend happen on top of
> > > Struts. Something
> > > that takes Struts, a proven OSS O/R framework, and some 
> glue to make
> > > DB-driven Struts applications faster to develop.
> > >
> > > Anything like that out there? Anyone working on this or have
> > > one in the
> > > planning stages? I've been wanting to craft one myself, but
> > > haven't had
> > > the time. But if one existed, I'd problem knock out a 
> couple of pet
> > > projects faster.
> >
> > I haven't used it, but I get the feeling that the Expresso framework
> > (http://www.jcorporate.com/) tries to fill this need to some extent.
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Robert J. Sanford, Jr.]

There are two things that I want/need in a persistence framework and I have
yet to find them. I know that OJB does not support them and I have not
looked very hard at the others. Maybe you can tell me if your product
handles them.

1) Read only attributes so that a setter method is not automatically
generated for one and that value is never persisted, just read.

2) The ability to persist an object to a different "table" than it was read
from. Yes this seems odd so let me explain in a few simple words followed by
a simplistic example. The simple words are - performance and simplicity.
When developing a web app database I tend to go for normalization. The
employees are in one table with a FK to the department table. But, when
displaying the data on a page I want to display the name of the department,
not its database ID. So, I use a view that joins the two tables meaning that
   a) I get all the data that I need in a single query I can
  get all of the information I need for display (performance)
  and...
   b) I don't have to worry about reading data from multiple
  queries and/or multiple objects (simplicity).

But, I cannot guarantee that the view I am reading from is updateable so I
have to insert/update to the simple tables (employee for instance).

So, can you help me out here? Can your product do this?

rjsjr

> -Original Message-
> From: Robert [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 4:12 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Persistence Framework Comparison?
>
>
> We have just released a free download for our eQ! software which you
> might want to take a look at: www.browsersoft.com/eQ
>
> The demo app is built using Struts for the controller, JSTL for taglibs,
> our persistence layer and our XML scripting engine for process logic.
>
> I'm the contact for it if you want more info.
>
> - Robert McIntosh
> [EMAIL PROTECTED]
>
> -Original Message-
> From: Karr, David [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 3:18 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Persistence Framework Comparison?
>
> > -Original Message-
> > From: James Higginbotham [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, October 04, 2002 1:12 PM
> > To: Struts Users Mailing List
> > Subject: RE: Persistence Framework Comparison?
> >
> >
> > > >(I wish Struts had a non implemented persistance interface)
> > >
> > > Really?  I think Struts is quite good at what it does, and to me,
> > > persistence seems to outside the scope of a web application MVC
> > > framework.
> >
> > Agreed. Struts does what it does best - web MVC framework. What the
> > original author of the comments (sorry, lost in my mailbox
> > right now) is
> > looking for is what I would recommend happen on top of
> > Struts. Something
> > that takes Struts, a proven OSS O/R framework, and some glue to make
> > DB-driven Struts applications faster to develop.
> >
> > Anything like that out there? Anyone working on this or have
> > one in the
> > planning stages? I've been wanting to craft one myself, but
> > haven't had
> > the time. But if one existed, I'd problem knock out a couple of pet
> > projects faster.
>
> I haven't used it, but I get the feeling that the Expresso framework
> (http://www.jcorporate.com/) tries to fill this need to some extent.
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Robert J. Sanford, Jr.]

There are two things that I want/need in a persistence framework and I have
yet to find them. I know that OJB does not support them and I have not
looked very hard at the others. Maybe you can tell me if Expresso handles
them.

1) Read only attributes so that a setter method is not automatically
generated for one and that value is never persisted, just read.

2) The ability to persist an object to a different "table" than it was read
from. Yes this seems odd so let me explain in a few simple words followed by
a simplistic example. The simple words are - performance and simplicity.
When developing a web app database I tend to go for normalization. The
employees are in one table with a FK to the department table. But, when
displaying the data on a page I want to display the name of the department,
not its database ID. So, I use a view that joins the two tables meaning that
   a) I get all the data that I need in a single query I can
  get all of the information I need for display (performance)
  and...
   b) I don't have to worry about reading data from multiple
  queries and/or multiple objects (simplicity).

But, I cannot guarantee that the view I am reading from is updateable so I
have to insert/update to the simple tables (employee for instance).

So, can you help me out here? Can Expresso do this?

rjsjr

> -Original Message-
> From: Sandra Cann [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 4:38 PM
> To: 'Struts Users Mailing List'
> Subject: RE: Persistence Framework Comparison?
>
>
> David,
>
> > > ...what I would recommend happen on top of Struts. Something
> > > that takes Struts, a proven OSS O/R framework, and some glue to make
> > > DB-driven Struts applications faster to develop.
> ...
> > > But if one existed, I'd problem knock out a couple of pet
> > > projects faster.
>
> One exists. :) Expresso is an architectural framework built around a
> core of 16 separate, integrated, application framework components - the
> glue to make DB-driven Struts applications.
>
> What makes Expresso noteworthy is:
> - it builds on several other open source projects - integrating best of
> breed open source components including Cactus, Log4J, JUnit, Xerces,
> Xalan, Struts and more into a single, integrated software architecture
> - it has the largest framework community globally (about 4500 on the
> listserv) - so most accepted
>
> > I haven't used it, but I get the feeling that the Expresso framework
> > (http://www.jcorporate.com/) tries to fill this need to some extent.
>
> That's exactly what Expresso provides :) and more. Here's a list of what
> it does:
>
> - Caching
> - Configuration Values
> - Controller Objects
> - Database Objects
> - DB Connection Pooling
> - Email Connectivity
> - Notification and Error Handling
> - Health Check
> - Job Control
> - Logging Integration
> - Registration & Login
> - Security
> - Taglibs
> - Unit Testing
> - Workflow
> - XML Integration
>
> Individually, each of these framework components solves technical
> challenges that developers traditionally must solve on their own before
> writing a given business application. Combined together, they solve
> innumerable application development challenges, and free a development
> team from having to write application architecture, allowing the team to
> focus on writing the applications that support the business at hand.
>
> With the 4.0 release, we replaced our own mvc with Struts'. We've
> released 4.1 RC3 download onsite which will be dubbed 4.1 this weekend.
> The 4.1 release is a major release with many many enhancements. If it
> has been some time since you looked at Expresso, please consider doing
> so again.
>
> Sandra
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Sandra Cann]

David,

> > ...what I would recommend happen on top of Struts. Something
> > that takes Struts, a proven OSS O/R framework, and some glue to make
> > DB-driven Struts applications faster to develop. 
...
> > But if one existed, I'd problem knock out a couple of pet
> > projects faster. 

One exists. :) Expresso is an architectural framework built around a
core of 16 separate, integrated, application framework components - the
glue to make DB-driven Struts applications. 

What makes Expresso noteworthy is:
- it builds on several other open source projects - integrating best of
breed open source components including Cactus, Log4J, JUnit, Xerces,
Xalan, Struts and more into a single, integrated software architecture 
- it has the largest framework community globally (about 4500 on the
listserv) - so most accepted 

> I haven't used it, but I get the feeling that the Expresso framework
> (http://www.jcorporate.com/) tries to fill this need to some extent.

That's exactly what Expresso provides :) and more. Here's a list of what
it does:

- Caching 
- Configuration Values 
- Controller Objects 
- Database Objects 
- DB Connection Pooling 
- Email Connectivity 
- Notification and Error Handling 
- Health Check 
- Job Control 
- Logging Integration
- Registration & Login 
- Security 
- Taglibs 
- Unit Testing 
- Workflow  
- XML Integration

Individually, each of these framework components solves technical
challenges that developers traditionally must solve on their own before
writing a given business application. Combined together, they solve
innumerable application development challenges, and free a development
team from having to write application architecture, allowing the team to
focus on writing the applications that support the business at hand.

With the 4.0 release, we replaced our own mvc with Struts'. We've
released 4.1 RC3 download onsite which will be dubbed 4.1 this weekend.
The 4.1 release is a major release with many many enhancements. If it
has been some time since you looked at Expresso, please consider doing
so again.

Sandra




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[OT] RE: Persistence Framework Comparison?

[David Graham]

I think you missed the point.  Yes, JDO lets you program to an interface 
with multiple vendors competing on implementations.  But what if you don't 
want to use JDO?

This is a layer above all persistence frameworks (JDBC, JDO, EJB, OJB, etc.) 
that your application programs to.  If you decide to change persistence 
frameworks, most of your code remains unchanged because it doesn't know 
which one you're using.

I, and others, have rolled our own but I think it would be useful for 
Jakarta Commons to provide this framework (similar to their logging api).

Dave


>From: "James Higginbotham" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Subject: RE: Persistence Framework Comparison?
>Date: Fri, 4 Oct 2002 16:18:10 -0500
>
>Oh, then what you are looking for is the ODMG API for object databases,
>Sun's JDO (not Castor's JDO), or something similar. That is the purpose
>of those 2 APIs at least, abstracting object storage frameworks.
>
>James
>
> > -Original Message-
> > From: V. Cekvenich [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, October 04, 2002 4:03 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Persistence Framework Comparison?
> >
> >
> > (Sorry, I can't read inline comments)
> > "I'm curious why you think there would be any glue code needed?"
> >
> > It would not be Struts centric, agree. I have said to you Craig in
> > person that I think one of the many reasons Struts was so
> > successful is
> > that it stayed above the persistence fey.
> >
> > My wish was for a persistence or a ADO interface, and
> > interface only, in
> > Jakarta or else where respected.
> >
> > When the person I responded to said words to the effect " it
> > was painful
> > to switch persistence frameworks" I said I wish there was an
> > interface.
> >
> > If there were such an interface one could switch from JDO to
> > ORB to OJB
> > to EJB to Simper to DAORowset to xyz, assuming other followed the
> > interface. Let them compete.
> >
> > Such interfaces would have to be very light weight. (Ex:
> > find(), save(),
> > commit(), getProperty(""); setProperty("", Object))
> >
> > It could be used by anyone, not just all beans! WebServices,
> > JTable, etc.
> >
> > What it allows clients to do is make it easier to switch persistence
> > layer that they outgrow or does not have good support, etc.
> >
> > Sort of like we say presentation layer should be replaceable
> > and X:tag
> > and Stxx lets you go PDF or else, same shold be on persistence. We
> > should be able to switch.
> >
> > The glue is not one of my reasons at all. But it would make Struts
> > examples better. (One Struts book out there has a getter
> > property that
> > accesses the db connection in the getter!! But that is
> > not a Struts
> > issue.)
> >
> > This is not just theory, my clients use a DAO interface I
> > made up, that
> > I can wrap around major persistence layers. The beans are
> > isolated from
> > how this happens, and it works.
> > (this interfaces is public in a "good practices" sample Struts app,
> > everyone knows were).
> >
> > hth,
> > V.
> >
> >
> >
> >
> >
> >
> >
> >
> > Craig R. McClanahan wrote:
> > >
> > > On Fri, 4 Oct 2002, James Higginbotham wrote:
> > >
> > >
> > >>Date: Fri, 4 Oct 2002 15:11:53 -0500
> > >>From: James Higginbotham <[EMAIL PROTECTED]>
> > >>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > >>To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > >>Subject: RE: Persistence Framework Comparison?
> > >>
> > >>
> > >>>>(I wish Struts had a non implemented persistance interface)
> > >>>
> > >>>Really?  I think Struts is quite good at what it does, and to me,
> > >>>persistence seems to outside the scope of a web application MVC
> > >>>framework.
> > >>
> > >>Agreed. Struts does what it does best - web MVC framework. What the
> > >>original author of the comments (sorry, lost in my mailbox
> > right now)
> > >>is looking for is what I would recommend happen on top of Struts.
> > >>Something that takes Struts, a proven OSS O/R framework,
> > and some glue
>

RE: Persistence Framework Comparison?

[James Higginbotham]

Oh, then what you are looking for is the ODMG API for object databases,
Sun's JDO (not Castor's JDO), or something similar. That is the purpose
of those 2 APIs at least, abstracting object storage frameworks. 

James

> -Original Message-
> From: V. Cekvenich [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, October 04, 2002 4:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Persistence Framework Comparison?
> 
> 
> (Sorry, I can't read inline comments)
> "I'm curious why you think there would be any glue code needed?"
> 
> It would not be Struts centric, agree. I have said to you Craig in 
> person that I think one of the many reasons Struts was so 
> successful is 
> that it stayed above the persistence fey.
> 
> My wish was for a persistence or a ADO interface, and 
> interface only, in 
> Jakarta or else where respected.
> 
> When the person I responded to said words to the effect " it 
> was painful 
> to switch persistence frameworks" I said I wish there was an 
> interface.
> 
> If there were such an interface one could switch from JDO to 
> ORB to OJB 
> to EJB to Simper to DAORowset to xyz, assuming other followed the 
> interface. Let them compete.
> 
> Such interfaces would have to be very light weight. (Ex: 
> find(), save(), 
> commit(), getProperty(""); setProperty("", Object))
> 
> It could be used by anyone, not just all beans! WebServices, 
> JTable, etc.
> 
> What it allows clients to do is make it easier to switch persistence 
> layer that they outgrow or does not have good support, etc.
> 
> Sort of like we say presentation layer should be replaceable 
> and X:tag 
> and Stxx lets you go PDF or else, same shold be on persistence. We 
> should be able to switch.
> 
> The glue is not one of my reasons at all. But it would make Struts 
> examples better. (One Struts book out there has a getter 
> property that 
> accesses the db connection in the getter!! But that is 
> not a Struts 
> issue.)
> 
> This is not just theory, my clients use a DAO interface I 
> made up, that 
> I can wrap around major persistence layers. The beans are 
> isolated from 
> how this happens, and it works.
> (this interfaces is public in a "good practices" sample Struts app, 
> everyone knows were).
> 
> hth,
> V.
> 
> 
> 
> 
> 
> 
> 
> 
> Craig R. McClanahan wrote:
> > 
> > On Fri, 4 Oct 2002, James Higginbotham wrote:
> > 
> > 
> >>Date: Fri, 4 Oct 2002 15:11:53 -0500
> >>From: James Higginbotham <[EMAIL PROTECTED]>
> >>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >>To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >>Subject: RE: Persistence Framework Comparison?
> >>
> >>
> >>>>(I wish Struts had a non implemented persistance interface)
> >>>
> >>>Really?  I think Struts is quite good at what it does, and to me, 
> >>>persistence seems to outside the scope of a web application MVC 
> >>>framework.
> >>
> >>Agreed. Struts does what it does best - web MVC framework. What the 
> >>original author of the comments (sorry, lost in my mailbox 
> right now) 
> >>is looking for is what I would recommend happen on top of Struts. 
> >>Something that takes Struts, a proven OSS O/R framework, 
> and some glue 
> >>to make DB-driven Struts applications faster to develop.
> >>
> > 
> > 
> > If I ever had time to work on such a framework, I'd 
> probably do it in 
> > the Commons project at Apache, because it would be generally useful 
> > (both inside and outside of Struts).  Alas, given my work schedule, 
> > assuming I'd have time for this is probably wishful thinking :-).
> > 
> > But, I'm curious why you think there would be any glue code 
> needed?  
> > Isn't it just a matter of using the persistence framework directly 
> > from your DAOs (or from your Actions if you don't use 
> DAOs)?  At most, 
> > I could only conceive of perhaps providing a Struts PlugIn to 
> > initialize such a framework, but maybe I'm missing something.
> > 
> > What would definitely be useful is some example apps that 
> illustrate 
> > how apps can leverage things like this.  There are several 
> pointers in 
> > the Resources pages to such things.
> > 
> > 
> >>Anything like that out there? Anyone working on this or have one in 
> >>the planning stages? I've been wanting to craft one myself, but 
> >>haven't had the time. But if one existed, I'd problem knock out a 
> >>couple of pet projects faster.
> >>
> >>James
> >>
> > 
> > 
> > Craig
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:struts-user-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Robert]

We have just released a free download for our eQ! software which you
might want to take a look at: www.browsersoft.com/eQ

The demo app is built using Struts for the controller, JSTL for taglibs,
our persistence layer and our XML scripting engine for process logic.

I'm the contact for it if you want more info.

- Robert McIntosh
[EMAIL PROTECTED]

-Original Message-
From: Karr, David [mailto:[EMAIL PROTECTED]] 
Sent: Friday, October 04, 2002 3:18 PM
To: 'Struts Users Mailing List'
Subject: RE: Persistence Framework Comparison?

> -Original Message-
> From: James Higginbotham [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 1:12 PM
> To: Struts Users Mailing List
> Subject: RE: Persistence Framework Comparison?
> 
> 
> > >(I wish Struts had a non implemented persistance interface)
> > 
> > Really?  I think Struts is quite good at what it does, and to me, 
> > persistence seems to outside the scope of a web application MVC 
> > framework.
> 
> Agreed. Struts does what it does best - web MVC framework. What the
> original author of the comments (sorry, lost in my mailbox 
> right now) is
> looking for is what I would recommend happen on top of 
> Struts. Something
> that takes Struts, a proven OSS O/R framework, and some glue to make
> DB-driven Struts applications faster to develop. 
> 
> Anything like that out there? Anyone working on this or have 
> one in the
> planning stages? I've been wanting to craft one myself, but 
> haven't had
> the time. But if one existed, I'd problem knock out a couple of pet
> projects faster. 

I haven't used it, but I get the feeling that the Expresso framework
(http://www.jcorporate.com/) tries to fill this need to some extent.

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Persistence Framework Comparison?

[V. Cekvenich]

(Sorry, I can't read inline comments)
"I'm curious why you think there would be any glue code needed?"

It would not be Struts centric, agree. I have said to you Craig in 
person that I think one of the many reasons Struts was so successful is 
that it stayed above the persistence fey.

My wish was for a persistence or a ADO interface, and interface only, in 
Jakarta or else where respected.

When the person I responded to said words to the effect " it was painful 
to switch persistence frameworks" I said I wish there was an interface.

If there were such an interface one could switch from JDO to ORB to OJB 
to EJB to Simper to DAORowset to xyz, assuming other followed the 
interface. Let them compete.

Such interfaces would have to be very light weight. (Ex: find(), save(), 
commit(), getProperty(""); setProperty("", Object))

It could be used by anyone, not just all beans! WebServices, JTable, etc.

What it allows clients to do is make it easier to switch persistence 
layer that they outgrow or does not have good support, etc.

Sort of like we say presentation layer should be replaceable and X:tag 
and Stxx lets you go PDF or else, same shold be on persistence. We 
should be able to switch.

The glue is not one of my reasons at all. But it would make Struts 
examples better. (One Struts book out there has a getter property that 
accesses the db connection in the getter!! But that is not a Struts 
issue.)

This is not just theory, my clients use a DAO interface I made up, that 
I can wrap around major persistence layers. The beans are isolated from 
how this happens, and it works.
(this interfaces is public in a "good practices" sample Struts app, 
everyone knows were).

hth,
V.








Craig R. McClanahan wrote:
> 
> On Fri, 4 Oct 2002, James Higginbotham wrote:
> 
> 
>>Date: Fri, 4 Oct 2002 15:11:53 -0500
>>From: James Higginbotham <[EMAIL PROTECTED]>
>>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>>Subject: RE: Persistence Framework Comparison?
>>
>>
>>>>(I wish Struts had a non implemented persistance interface)
>>>
>>>Really?  I think Struts is quite good at what it does, and to me,
>>>persistence seems to outside the scope of a web application MVC
>>>framework.
>>
>>Agreed. Struts does what it does best - web MVC framework. What the
>>original author of the comments (sorry, lost in my mailbox right now) is
>>looking for is what I would recommend happen on top of Struts. Something
>>that takes Struts, a proven OSS O/R framework, and some glue to make
>>DB-driven Struts applications faster to develop.
>>
> 
> 
> If I ever had time to work on such a framework, I'd probably do it in the
> Commons project at Apache, because it would be generally useful (both
> inside and outside of Struts).  Alas, given my work schedule, assuming I'd
> have time for this is probably wishful thinking :-).
> 
> But, I'm curious why you think there would be any glue code needed?  Isn't
> it just a matter of using the persistence framework directly from your
> DAOs (or from your Actions if you don't use DAOs)?  At most, I could only
> conceive of perhaps providing a Struts PlugIn to initialize such a
> framework, but maybe I'm missing something.
> 
> What would definitely be useful is some example apps that illustrate how
> apps can leverage things like this.  There are several pointers in the
> Resources pages to such things.
> 
> 
>>Anything like that out there? Anyone working on this or have one in the
>>planning stages? I've been wanting to craft one myself, but haven't had
>>the time. But if one existed, I'd problem knock out a couple of pet
>>projects faster.
>>
>>James
>>
> 
> 
> Craig




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[David Graham]

Craig,
You're right that your DAOs would be implemented using one of the "mapping" 
technologies (JDBC, OJB, EJB, JDO, Castor, etc,).  However, what is useful 
is a framework of helper classes that aid in implementing DAOs for a given 
technology.  I have implemented this framework and it's very lightweight but 
extremely useful.

I have a MapperFactory (mapper is the same idea as a dao) that will return a 
Mapper implementation class given a domain class' Class.  Also, my jdbc 
mappers descend from the JdbcMapper class that provides common jdbc services 
like rollback and commit and dealing with SQLExceptions.  This has cut down 
on the amount of sql error code I write.

Similar parent classes (ie. EjbMapper, JdoMapper) would provide common 
services but I'm not familiar enough with them yet to implement it.

Dave


>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: Struts Users Mailing List <[EMAIL PROTECTED]>
>Subject: RE: Persistence Framework Comparison?
>Date: Fri, 4 Oct 2002 13:39:10 -0700 (PDT)
>
>
>
>On Fri, 4 Oct 2002, James Higginbotham wrote:
>
> > Date: Fri, 4 Oct 2002 15:11:53 -0500
> > From: James Higginbotham <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > Subject: RE: Persistence Framework Comparison?
> >
> > > >(I wish Struts had a non implemented persistance interface)
> > >
> > > Really?  I think Struts is quite good at what it does, and to me,
> > > persistence seems to outside the scope of a web application MVC
> > > framework.
> >
> > Agreed. Struts does what it does best - web MVC framework. What the
> > original author of the comments (sorry, lost in my mailbox right now) is
> > looking for is what I would recommend happen on top of Struts. Something
> > that takes Struts, a proven OSS O/R framework, and some glue to make
> > DB-driven Struts applications faster to develop.
> >
>
>If I ever had time to work on such a framework, I'd probably do it in the
>Commons project at Apache, because it would be generally useful (both
>inside and outside of Struts).  Alas, given my work schedule, assuming I'd
>have time for this is probably wishful thinking :-).
>
>But, I'm curious why you think there would be any glue code needed?  Isn't
>it just a matter of using the persistence framework directly from your
>DAOs (or from your Actions if you don't use DAOs)?  At most, I could only
>conceive of perhaps providing a Struts PlugIn to initialize such a
>framework, but maybe I'm missing something.
>
>What would definitely be useful is some example apps that illustrate how
>apps can leverage things like this.  There are several pointers in the
>Resources pages to such things.
>
> > Anything like that out there? Anyone working on this or have one in the
> > planning stages? I've been wanting to craft one myself, but haven't had
> > the time. But if one existed, I'd problem knock out a couple of pet
> > projects faster.
> >
> > James
> >
>
>Craig
>
>
>--
>To unsubscribe, e-mail:   
><mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: 
><mailto:[EMAIL PROTECTED]>




_
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[James Higginbotham]

> But, I'm curious why you think there would be any glue code 
> needed?  Isn't it just a matter of using the persistence 
> framework directly from your DAOs (or from your Actions if 
> you don't use DAOs)?  At most, I could only conceive of 
> perhaps providing a Struts PlugIn to initialize such a 
> framework, but maybe I'm missing something.
>

I'm visualizing the glue being something such as smarter actions that
know how to do CRUD actions against the chosen framework given an O/R
enabled model. Various actions that can deal a simple form,
Master/Detail, multiple step wizards, and other forms of data entry to
push data to the O/R layer. Yes, there have been many posts and
solutions offered for doing each, but offering a framework with examples
that get all the redundant work out of the way would be helpful. It
wouldn't be a big project, but a worthy endeavour none-the-less. 


In fact, depending on how fancy and brown bag you want things, you could
also offer, in addition to the smarter actions, some XML-driven
configuration files that define the action names, corresponding classes
to manage, the actions to take (read, create, update, delete, all), the
master/detail or form-to-page mappings, and viola, you are deploying
dynamically generated Struts actions and configuration entries to do
everything for you. Thus, you begin to get closer to using something
like Turbine to tie it all together by having it create your tables (if
you are doing something new), building your data entry screens using
this XML (or some other) configuration file, and all the magic happens
within this mythical framework.

Of course, mileage varies, as everyone's requirements are different, but
many times I've just had a 1-to-1 mapping from DB to UI where I used to
use NetDynamics or something RAD to gen the screens. 


James

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Persistence Framework Comparison?

[Lowe, Jeff]

>> Does anybody know a of a decent comparison of Open Source persistence 
frameworks?

http://c2.com/cgi-bin/wiki?CayenneVsOther

You decide if its decent.

-Jeff



-Original Message-
From: Adam Sherman [mailto:[EMAIL PROTECTED]] 
Sent: Friday, October 04, 2002 12:30 PM
To: Struts Users Mailing List
Subject: Persistence Framework Comparison?


Does anybody know a of a decent comparison of Open Source persistence 
frameworks?

I'm embarking on a big project without time to properly evaluate them. 
So I need some help deciding.

Thanks,

A.

-- 
Adam Sherman
Software Developer
Teach and Travel Inc.
+1.613.241.3103



--
To unsubscribe, e-mail:

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Persistence Framework Comparison?

[Craig R. McClanahan]

On Fri, 4 Oct 2002, James Higginbotham wrote:

> Date: Fri, 4 Oct 2002 15:11:53 -0500
> From: James Higginbotham <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Persistence Framework Comparison?
>
> > >(I wish Struts had a non implemented persistance interface)
> >
> > Really?  I think Struts is quite good at what it does, and to me,
> > persistence seems to outside the scope of a web application MVC
> > framework.
>
> Agreed. Struts does what it does best - web MVC framework. What the
> original author of the comments (sorry, lost in my mailbox right now) is
> looking for is what I would recommend happen on top of Struts. Something
> that takes Struts, a proven OSS O/R framework, and some glue to make
> DB-driven Struts applications faster to develop.
>

If I ever had time to work on such a framework, I'd probably do it in the
Commons project at Apache, because it would be generally useful (both
inside and outside of Struts).  Alas, given my work schedule, assuming I'd
have time for this is probably wishful thinking :-).

But, I'm curious why you think there would be any glue code needed?  Isn't
it just a matter of using the persistence framework directly from your
DAOs (or from your Actions if you don't use DAOs)?  At most, I could only
conceive of perhaps providing a Struts PlugIn to initialize such a
framework, but maybe I'm missing something.

What would definitely be useful is some example apps that illustrate how
apps can leverage things like this.  There are several pointers in the
Resources pages to such things.

> Anything like that out there? Anyone working on this or have one in the
> planning stages? I've been wanting to craft one myself, but haven't had
> the time. But if one existed, I'd problem knock out a couple of pet
> projects faster.
>
> James
>

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[Karr, David]

> -Original Message-
> From: James Higginbotham [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 1:12 PM
> To: Struts Users Mailing List
> Subject: RE: Persistence Framework Comparison?
> 
> 
> > >(I wish Struts had a non implemented persistance interface)
> > 
> > Really?  I think Struts is quite good at what it does, and to me, 
> > persistence seems to outside the scope of a web application MVC 
> > framework.
> 
> Agreed. Struts does what it does best - web MVC framework. What the
> original author of the comments (sorry, lost in my mailbox 
> right now) is
> looking for is what I would recommend happen on top of 
> Struts. Something
> that takes Struts, a proven OSS O/R framework, and some glue to make
> DB-driven Struts applications faster to develop. 
> 
> Anything like that out there? Anyone working on this or have 
> one in the
> planning stages? I've been wanting to craft one myself, but 
> haven't had
> the time. But if one existed, I'd problem knock out a couple of pet
> projects faster. 

I haven't used it, but I get the feeling that the Expresso framework
(http://www.jcorporate.com/) tries to fill this need to some extent.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Persistence Framework Comparison?

[James Higginbotham]

> >(I wish Struts had a non implemented persistance interface)
> 
> Really?  I think Struts is quite good at what it does, and to me, 
> persistence seems to outside the scope of a web application MVC 
> framework.

Agreed. Struts does what it does best - web MVC framework. What the
original author of the comments (sorry, lost in my mailbox right now) is
looking for is what I would recommend happen on top of Struts. Something
that takes Struts, a proven OSS O/R framework, and some glue to make
DB-driven Struts applications faster to develop. 

Anything like that out there? Anyone working on this or have one in the
planning stages? I've been wanting to craft one myself, but haven't had
the time. But if one existed, I'd problem knock out a couple of pet
projects faster. 

James

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Persistence Framework Comparison?

[Joe Germuska]

At 2:31 PM -0400 2002/10/04, V. Cekvenich wrote:
>(I wish Struts had a non implemented persistance interface)

Really?  I think Struts is quite good at what it does, and to me, 
persistence seems to outside the scope of a web application MVC 
framework.

Why do you wish that Struts had this?  Because the Struts team 
develops really good code?  Or because you really wish that a 
persistence interface had tight integration with Struts?

I think part of how the team produces good code is by maintaining focus.

While we're on the topic of persistence, I'm pretty happy with OJB 
after just rolling out one project with it.  I wrote a light 
interface over it to insulate my code from the fact that I was using 
OJB, but the interface is so much like the PersistenceBroker 
interface in OJB that I'm thinking about skipping it for my next 
implementation.  OJB looks like it's well enough designed that you 
could completely replace the implementation with anything else you 
wanted just by writing an adapter that implemented PersistenceBroker, 
making my lightweight wrapper around it kind of a waste of time.

I have reservations about Castor JDO -- compare source code from that 
to source code from Struts and you'll see why!  I don't have much 
experience with other persistence toolkits...

Joe

-- 
--
* Joe Germuska{ [EMAIL PROTECTED] }
"It's pitiful, sometimes, if they've got it bad. Their eyes get 
glazed, they go white, their hands tremble As I watch them I 
often feel that a dope peddler is a gentleman compared with the man 
who sells records."
--Sam Goody, 1956

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Persistence Framework Comparison?

[V. Cekvenich]

It is possible that one could change persistence later. Been there done 
that, got the T -Shirt.

There is JDO, Jakarta ORB, my own DAORowSet, Simper, EJB, etc. etc.

Now, so that I can change persistance, my bean calls the persistance via 
an very simple interface and via the interface only!.

Here is my 
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/basicPortal_07/src/org/commons/DAO/BasicDAO.java?rev=1.2&content-type=text/vnd.viewcvs-markup
goal is that any persistance could do this at least.

(I wish Struts had a non implemented persistance interface)

This way I am able to switch.

.V

Adam Sherman wrote:
> Galbreath, Mark wrote:
> 
>> Isn't that always the case?  :-(
> 
> 
> No kidding, putting a ton of work into something only to realize that 
> that "other" tool could have done most of it for you is *very* unpleasant.
> 
> A.
> 
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Persistence Framework Comparison?

[Peter S. Hamlen]

Search the message list - this got asked just a few days ago.  Or google
on "Castor Torque Hibernate"

Here's an interesting letter that might help:
http://www.mail-archive.com/mav-user@lists.sourceforge.net/msg00190.html

Personally, I've been using Torque for two projects now and I think it's
the greatest thing since sliced bread.  It does everything I need it to
do - with the small exception that it doesn't handle "outer joins" too
well.  

But the fact that it essentially generates Java classes that operate as
nested beans makes my life really great with Struts.  Unless
security/control is a big issue, I can just place the base object (in my
case, a Person) into a form and reference everything via nested
properties (ie, person.currentAddress.city, person.orders, etc.)  Plus,
if you enable it, calling Save on the person object will call Save on
all the children objects - allowing you to update everything about a
person on one page and then just call "save".  Works like a charm for
me.

-Peter

On Fri, 2002-10-04 at 12:29, Adam Sherman wrote:
> Does anybody know a of a decent comparison of Open Source persistence 
> frameworks?
> 
> I'm embarking on a big project without time to properly evaluate them. 
> So I need some help deciding.
> 
> Thanks,
> 
> A.
> 
> -- 
> Adam Sherman
> Software Developer
> Teach and Travel Inc.
> +1.613.241.3103
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Persistence Framework Comparison?

[Adam Sherman]

Galbreath, Mark wrote:
> Isn't that always the case?  :-(

No kidding, putting a ton of work into something only to realize that 
that "other" tool could have done most of it for you is *very* unpleasant.

A.


-- 
Adam Sherman
Software Developer
Teach and Travel Inc.
+1.613.241.3103



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Persistence Framework Comparison?

[Galbreath, Mark]

Isn't that always the case?  :-(

-Original Message-
From: Adam Sherman [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 04, 2002 12:30 PM

I'm embarking on a big project without time to properly evaluate them. 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Persistence Framework Comparison?

[Dan Cancro]

Here's one from Cayenne: http://c2.com/cgi-bin/wiki?CayenneVsOther


> -Original Message-
> From: Adam Sherman [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 9:30 AM
> To: Struts Users Mailing List
> Subject: Persistence Framework Comparison?
> 
> 
> Does anybody know a of a decent comparison of Open Source persistence 
> frameworks?
> 
> I'm embarking on a big project without time to properly 
> evaluate them. 
> So I need some help deciding.
> 
> Thanks,
> 
> A.
> 
> -- 
> Adam Sherman
> Software Developer
> Teach and Travel Inc.
> +1.613.241.3103
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: