Re: Design Advice - Relational Databases & Java Objects

[@Basebeans.com]

Subject: Re: Design Advice - Relational Databases & Java Objects
From: Jeff Duska <[EMAIL PROTECTED]>
 ===
I think this is the point that Vic was making. The transaction that you 
will thinking of in the application might not nicely map to simple DAO 
objects. While I might have Order and Order Items in the database, I 
must like might not want to have two seperate DAO objects. I might 
create just a Order object, which has a collection of items.

I think approaches, if I understand them, Martin Fowler recommends the 
Transaction Scripts design pattern or you could use a data mapping design.

Another way to do this is command pattern that Bruce Tate uses in his 
Bitter Java. My only concern with this design was that seemed to offer 
less reuse. I'm only have half way through books, so maybe I've missed a 
section on this.

What would be nice to find more examples that explain both the pros and 
cons. Vic has placed is project out there on Basebeans, but I'm not sure 
that this covered in it. I haven't looked at in detail yet.

Regards,

Jeff Duska


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

Re: Design Advice - Relational Databases & Java Objects

[Roy Truelove]

Have you looking into Torque at all?
(http://jakarta.apache.org/turbine/torque/index.html) It's been recently
decoupled from Turbine and offers excellent object-> relational mapping.  I
have about 30 tables in my project and haven't written any SQL yet!

Good luck,
Roy

- Original Message -
From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, June 05, 2002 4:19 PM
Subject: Re: Design Advice - Relational Databases & Java Objects


> ... (still being dim) ... but how do the DAOs see the Transaction object?
>
> Robert Taylor wrote:
>
> >The DAOs have a method called getConnection(). Inside getConnection()
they
> >call
> >Transaction.getTransactionContext(). TransactionContext contains the
> >Connection and
> >other information about the Transaction. Although, TransactionContext is
> >held within
> >the static ThreadLocal variable, it is garanteed to be unique for each
> >thread, thus
> >providing the same Connection for all DAOs in the same thread that join
the
> >transaction.
> >
> >HTH,
> >
> >robert
> >
> >
> >
> >>-----Original Message-----
> >>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
> >>Sent: Wednesday, June 05, 2002 2:33 AM
> >>To: Struts Users Mailing List
> >>Subject: Re: Design Advice - Relational Databases & Java Objects
> >>
> >>
> >>Aha, ThreadLocal. Sounds good, but I still have problems working out how
> >>the DAOs get there. OK, I'm possibly being a bit dim here - how does the
> >>DAO access the ThreadLocal holding your connection?
> >>
> >>Robert Taylor wrote:
> >>
> >>
> >>
> >>>Transaction makes the same Connection available to all
> >>>DAOs in the same thread by storing it in a ThreadLocal
> >>>variable, so I don't have to pass the transaction around.
> >>>
> >>>robert
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>-Original Message-
> >>>>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
> >>>>Sent: Tuesday, June 04, 2002 4:46 PM
> >>>>To: Struts Users Mailing List
> >>>>Subject: Re: Design Advice - Relational Databases & Java Objects
> >>>>
> >>>>
> >>>>Hi Robert,
> >>>>that is more or less what I am aiming to do. I see you don't pass
> >>>>connections around - at least not across your business to DAO
interface.
> >>>>So from your code snippet, I guess your transaction object gets the
> >>>>connection and puts it somewhere that the DAOs can find it? Or do you
> >>>>pass your transaction object into your DAOs via their constructors?
> >>>>
> >>>>I am going with the struts connection pool so I'm thinking how I can
> >>>>wrap them up without having to repeat lots of error handling in the
> >>>>business objects.
> >>>>
> >>>>Regards
> >>>>Adam
> >>>>
> >>>>Robert Taylor wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Adam, when I first started using DAO in my application,
> >>>>>I had course grained DAO's that encapsulated transactions.
> >>>>>They were responsible for managing the transaction boundries
> >>>>>(getting the connection, committing or rolling back, and then
> >>>>>releasing the connection). I then found that they were not
> >>>>>as reusable and they contained a lot of business logic. I started
> >>>>>thinking, this doesn't make sense. To me, it was more intuitive
> >>>>>that the DAO should only be responsible for data access and
> >>>>>the business logic and transaction management should be a layer
> >>>>>above the DAO. So now, my business objects are responsible for
> >>>>>managing the transaction (actually they delegate it to another
> >>>>>module) and DAOs "join" the transaction in progress. The DAO
> >>>>>become more reusable and are decoupled from the mechanism that
> >>>>>manages the transaction. So now I have something like the
> >>>>>following:
> >>>>>
> >>>>>ITransaction trans = // get a transaction object
> >>>>>
> >>>>>

Re: Design Advice - Relational Databases & Java Objects

[Robert Taylor]

Transaction lives in the VM and therefore the DAOs
have access to its static methods which are used to
get the Connection in the current thread via the
methods described below.

If you have any further questions about
implementation,
please email me directly, [EMAIL PROTECTED], so we
can cut down on topics not directly related to Struts.

robert


--- Adam Hardy <[EMAIL PROTECTED]> wrote:
> ... (still being dim) ... but how do the DAOs see
> the Transaction object?
> 
> Robert Taylor wrote:
> 
> >The DAOs have a method called getConnection().
> Inside getConnection() they
> >call
> >Transaction.getTransactionContext().
> TransactionContext contains the
> >Connection and
> >other information about the Transaction. Although,
> TransactionContext is
> >held within
> >the static ThreadLocal variable, it is garanteed to
> be unique for each
> >thread, thus
> >providing the same Connection for all DAOs in the
> same thread that join the
> >transaction.
> >
> >HTH,
> >
> >robert
> >
> >  
> >
> >>-Original Message-----
> >>From: Adam Hardy
> [mailto:[EMAIL PROTECTED]]
> >>Sent: Wednesday, June 05, 2002 2:33 AM
> >>To: Struts Users Mailing List
> >>Subject: Re: Design Advice - Relational Databases
> & Java Objects
> >>
> >>
> >>Aha, ThreadLocal. Sounds good, but I still have
> problems working out how
> >>the DAOs get there. OK, I'm possibly being a bit
> dim here - how does the
> >>DAO access the ThreadLocal holding your
> connection?
> >>
> >>Robert Taylor wrote:
> >>
> >>
> >>
> >>>Transaction makes the same Connection available
> to all
> >>>DAOs in the same thread by storing it in a
> ThreadLocal
> >>>variable, so I don't have to pass the transaction
> around.
> >>>
> >>>robert
> >>>
> >>>
> >>>
> >>>  
> >>>
> >>>>-Original Message-
> >>>>From: Adam Hardy
> [mailto:[EMAIL PROTECTED]]
> >>>>Sent: Tuesday, June 04, 2002 4:46 PM
> >>>>To: Struts Users Mailing List
> >>>>Subject: Re: Design Advice - Relational
> Databases & Java Objects
> >>>>
> >>>>
> >>>>Hi Robert,
> >>>>that is more or less what I am aiming to do. I
> see you don't pass
> >>>>connections around - at least not across your
> business to DAO interface.
> >>>>So from your code snippet, I guess your
> transaction object gets the
> >>>>connection and puts it somewhere that the DAOs
> can find it? Or do you
> >>>>pass your transaction object into your DAOs via
> their constructors?
> >>>>
> >>>>I am going with the struts connection pool so
> I'm thinking how I can
> >>>>wrap them up without having to repeat lots of
> error handling in the
> >>>>business objects.
> >>>>
> >>>>Regards
> >>>>Adam
> >>>>
> >>>>Robert Taylor wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Adam, when I first started using DAO in my
> application,
> >>>>>I had course grained DAO's that encapsulated
> transactions.
> >>>>>They were responsible for managing the
> transaction boundries
> >>>>>(getting the connection, committing or rolling
> back, and then
> >>>>>releasing the connection). I then found that
> they were not
> >>>>>as reusable and they contained a lot of
> business logic. I started
> >>>>>thinking, this doesn't make sense. To me, it
> was more intuitive
> >>>>>that the DAO should only be responsible for
> data access and
> >>>>>the business logic and transaction management
> should be a layer
> >>>>>above the DAO. So now, my business objects are
> responsible for
> >>>>>managing the transaction (actually they
> delegate it to another
> >>>>>module) and DAOs "join" the transaction in
> progress. The DAO
> >>>>>become more reusable and are decoupled from the
> mechanism that
> >>>>>manages the transaction. So now I have
> something like the
> >>>>>following:
> >>>>>
> >>>>>ITransaction trans = // get 

Re: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

... (still being dim) ... but how do the DAOs see the Transaction object?

Robert Taylor wrote:

>The DAOs have a method called getConnection(). Inside getConnection() they
>call
>Transaction.getTransactionContext(). TransactionContext contains the
>Connection and
>other information about the Transaction. Although, TransactionContext is
>held within
>the static ThreadLocal variable, it is garanteed to be unique for each
>thread, thus
>providing the same Connection for all DAOs in the same thread that join the
>transaction.
>
>HTH,
>
>robert
>
>  
>
>>-Original Message-
>>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, June 05, 2002 2:33 AM
>>To: Struts Users Mailing List
>>Subject: Re: Design Advice - Relational Databases & Java Objects
>>
>>
>>Aha, ThreadLocal. Sounds good, but I still have problems working out how
>>the DAOs get there. OK, I'm possibly being a bit dim here - how does the
>>DAO access the ThreadLocal holding your connection?
>>
>>Robert Taylor wrote:
>>
>>
>>
>>>Transaction makes the same Connection available to all
>>>DAOs in the same thread by storing it in a ThreadLocal
>>>variable, so I don't have to pass the transaction around.
>>>
>>>robert
>>>
>>>
>>>
>>>  
>>>
>>>>-Original Message-
>>>>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
>>>>Sent: Tuesday, June 04, 2002 4:46 PM
>>>>To: Struts Users Mailing List
>>>>Subject: Re: Design Advice - Relational Databases & Java Objects
>>>>
>>>>
>>>>Hi Robert,
>>>>that is more or less what I am aiming to do. I see you don't pass
>>>>connections around - at least not across your business to DAO interface.
>>>>So from your code snippet, I guess your transaction object gets the
>>>>connection and puts it somewhere that the DAOs can find it? Or do you
>>>>pass your transaction object into your DAOs via their constructors?
>>>>
>>>>I am going with the struts connection pool so I'm thinking how I can
>>>>wrap them up without having to repeat lots of error handling in the
>>>>business objects.
>>>>
>>>>Regards
>>>>Adam
>>>>
>>>>Robert Taylor wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Adam, when I first started using DAO in my application,
>>>>>I had course grained DAO's that encapsulated transactions.
>>>>>They were responsible for managing the transaction boundries
>>>>>(getting the connection, committing or rolling back, and then
>>>>>releasing the connection). I then found that they were not
>>>>>as reusable and they contained a lot of business logic. I started
>>>>>thinking, this doesn't make sense. To me, it was more intuitive
>>>>>that the DAO should only be responsible for data access and
>>>>>the business logic and transaction management should be a layer
>>>>>above the DAO. So now, my business objects are responsible for
>>>>>managing the transaction (actually they delegate it to another
>>>>>module) and DAOs "join" the transaction in progress. The DAO
>>>>>become more reusable and are decoupled from the mechanism that
>>>>>manages the transaction. So now I have something like the
>>>>>following:
>>>>>
>>>>>ITransaction trans = // get a transaction object
>>>>>
>>>>>try {
>>>>>
>>>>>  trans.begin();
>>>>>
>>>>>  dao1.insert(dto);
>>>>>  dto2.setForeignKeyId(dto.getIdentity());
>>>>>  dto3.setForeignKeyId(dao1.getIdentity());
>>>>>
>>>>>  dao2.insert();
>>>>>  dao3.insert();
>>>>>
>>>>>
>>>>>} catch (DatastoreException de) {
>>>>>
>>>>> trans.setRollbackOnly();
>>>>> throw new BusinessException(de);
>>>>>
>>>>>} finally {
>>>>>
>>>>>trans.end();
>>>>>
>>>>>}
>>>>>
>>>>>
>>>>>Each DAO joins the transaction (accesses the Connection in the
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>same thread)
>>>>

RE: Design Advice - Relational Databases & Java Objects

[Robert Taylor]

The DAOs have a method called getConnection(). Inside getConnection() they
call
Transaction.getTransactionContext(). TransactionContext contains the
Connection and
other information about the Transaction. Although, TransactionContext is
held within
the static ThreadLocal variable, it is garanteed to be unique for each
thread, thus
providing the same Connection for all DAOs in the same thread that join the
transaction.

HTH,

robert

> -Original Message-
> From: Adam Hardy [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 05, 2002 2:33 AM
> To: Struts Users Mailing List
> Subject: Re: Design Advice - Relational Databases & Java Objects
>
>
> Aha, ThreadLocal. Sounds good, but I still have problems working out how
> the DAOs get there. OK, I'm possibly being a bit dim here - how does the
> DAO access the ThreadLocal holding your connection?
>
> Robert Taylor wrote:
>
> >Transaction makes the same Connection available to all
> >DAOs in the same thread by storing it in a ThreadLocal
> >variable, so I don't have to pass the transaction around.
> >
> >robert
> >
> >
> >
> >>-Original Message-
> >>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
> >>Sent: Tuesday, June 04, 2002 4:46 PM
> >>To: Struts Users Mailing List
> >>Subject: Re: Design Advice - Relational Databases & Java Objects
> >>
> >>
> >>Hi Robert,
> >>that is more or less what I am aiming to do. I see you don't pass
> >>connections around - at least not across your business to DAO interface.
> >>So from your code snippet, I guess your transaction object gets the
> >>connection and puts it somewhere that the DAOs can find it? Or do you
> >>pass your transaction object into your DAOs via their constructors?
> >>
> >>I am going with the struts connection pool so I'm thinking how I can
> >>wrap them up without having to repeat lots of error handling in the
> >>business objects.
> >>
> >>Regards
> >>Adam
> >>
> >>Robert Taylor wrote:
> >>
> >>
> >>
> >>>Adam, when I first started using DAO in my application,
> >>>I had course grained DAO's that encapsulated transactions.
> >>>They were responsible for managing the transaction boundries
> >>>(getting the connection, committing or rolling back, and then
> >>>releasing the connection). I then found that they were not
> >>>as reusable and they contained a lot of business logic. I started
> >>>thinking, this doesn't make sense. To me, it was more intuitive
> >>>that the DAO should only be responsible for data access and
> >>>the business logic and transaction management should be a layer
> >>>above the DAO. So now, my business objects are responsible for
> >>>managing the transaction (actually they delegate it to another
> >>>module) and DAOs "join" the transaction in progress. The DAO
> >>>become more reusable and are decoupled from the mechanism that
> >>>manages the transaction. So now I have something like the
> >>>following:
> >>>
> >>>ITransaction trans = // get a transaction object
> >>>
> >>>try {
> >>>
> >>>   trans.begin();
> >>>
> >>>   dao1.insert(dto);
> >>>   dto2.setForeignKeyId(dto.getIdentity());
> >>>   dto3.setForeignKeyId(dao1.getIdentity());
> >>>
> >>>   dao2.insert();
> >>>   dao3.insert();
> >>>
> >>>
> >>>} catch (DatastoreException de) {
> >>>
> >>>  trans.setRollbackOnly();
> >>>  throw new BusinessException(de);
> >>>
> >>>} finally {
> >>>
> >>> trans.end();
> >>>
> >>>}
> >>>
> >>>
> >>>Each DAO joins the transaction (accesses the Connection in the
> >>>
> >>>
> >>same thread)
> >>
> >>
> >>>and uses it to perform the necessary data access operation. A nice side
> >>>effect
> >>>is that all the tediousness and complexity involved in managing the
> >>>transaction is
> >>>wrapped up in a simple API and not over multiple DAOs.
> >>>
> >>>Right now, I use straight JDBC but if I decided to use JDO or another
> >>>mechanism for transactions, my business client doesn't change.
> Just like
> >>>if I change my business logic, my web client (Strut

Re: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

Aha, ThreadLocal. Sounds good, but I still have problems working out how 
the DAOs get there. OK, I'm possibly being a bit dim here - how does the 
DAO access the ThreadLocal holding your connection?

Robert Taylor wrote:

>Transaction makes the same Connection available to all
>DAOs in the same thread by storing it in a ThreadLocal
>variable, so I don't have to pass the transaction around.
>
>robert
>
>  
>
>>-Original Message-
>>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, June 04, 2002 4:46 PM
>>To: Struts Users Mailing List
>>Subject: Re: Design Advice - Relational Databases & Java Objects
>>
>>
>>Hi Robert,
>>that is more or less what I am aiming to do. I see you don't pass
>>connections around - at least not across your business to DAO interface.
>>So from your code snippet, I guess your transaction object gets the
>>connection and puts it somewhere that the DAOs can find it? Or do you
>>pass your transaction object into your DAOs via their constructors?
>>
>>I am going with the struts connection pool so I'm thinking how I can
>>wrap them up without having to repeat lots of error handling in the
>>business objects.
>>
>>Regards
>>Adam
>>
>>Robert Taylor wrote:
>>
>>
>>
>>>Adam, when I first started using DAO in my application,
>>>I had course grained DAO's that encapsulated transactions.
>>>They were responsible for managing the transaction boundries
>>>(getting the connection, committing or rolling back, and then
>>>releasing the connection). I then found that they were not
>>>as reusable and they contained a lot of business logic. I started
>>>thinking, this doesn't make sense. To me, it was more intuitive
>>>that the DAO should only be responsible for data access and
>>>the business logic and transaction management should be a layer
>>>above the DAO. So now, my business objects are responsible for
>>>managing the transaction (actually they delegate it to another
>>>module) and DAOs "join" the transaction in progress. The DAO
>>>become more reusable and are decoupled from the mechanism that
>>>manages the transaction. So now I have something like the
>>>following:
>>>
>>>ITransaction trans = // get a transaction object
>>>
>>>try {
>>>
>>>   trans.begin();
>>>
>>>   dao1.insert(dto);
>>>   dto2.setForeignKeyId(dto.getIdentity());
>>>   dto3.setForeignKeyId(dao1.getIdentity());
>>>
>>>   dao2.insert();
>>>   dao3.insert();
>>>
>>>
>>>} catch (DatastoreException de) {
>>>
>>>  trans.setRollbackOnly();
>>>  throw new BusinessException(de);
>>>
>>>} finally {
>>>
>>> trans.end();
>>>
>>>}
>>>
>>>
>>>Each DAO joins the transaction (accesses the Connection in the
>>>  
>>>
>>same thread)
>>
>>
>>>and uses it to perform the necessary data access operation. A nice side
>>>effect
>>>is that all the tediousness and complexity involved in managing the
>>>transaction is
>>>wrapped up in a simple API and not over multiple DAOs.
>>>
>>>Right now, I use straight JDBC but if I decided to use JDO or another
>>>mechanism for transactions, my business client doesn't change. Just like
>>>if I change my business logic, my web client (Struts Action classes)
>>>don't have to change. I find this provides more cohesion within layers.
>>>That is, the business objects do business stuff by delegating to
>>>  
>>>
>>data access
>>
>>
>>>objects and data access objects just access data and tend to deal with
>>>tables
>>>that are related.
>>>
>>>This is just one way to do it, as Kevin already mentioned, there
>>>  
>>>
>>are other
>>
>>
>>>ways to skin this cat.
>>>
>>>HTH,
>>>
>>>robert
>>>
>>>
>>>--
>>>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: Design Advice - Relational Databases & Java Objects

[Robert Taylor]

Transaction makes the same Connection available to all
DAOs in the same thread by storing it in a ThreadLocal
variable, so I don't have to pass the transaction around.

robert

> -Original Message-
> From: Adam Hardy [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 04, 2002 4:46 PM
> To: Struts Users Mailing List
> Subject: Re: Design Advice - Relational Databases & Java Objects
>
>
> Hi Robert,
> that is more or less what I am aiming to do. I see you don't pass
> connections around - at least not across your business to DAO interface.
> So from your code snippet, I guess your transaction object gets the
> connection and puts it somewhere that the DAOs can find it? Or do you
> pass your transaction object into your DAOs via their constructors?
>
> I am going with the struts connection pool so I'm thinking how I can
> wrap them up without having to repeat lots of error handling in the
> business objects.
>
> Regards
> Adam
>
> Robert Taylor wrote:
>
> >Adam, when I first started using DAO in my application,
> >I had course grained DAO's that encapsulated transactions.
> >They were responsible for managing the transaction boundries
> >(getting the connection, committing or rolling back, and then
> >releasing the connection). I then found that they were not
> >as reusable and they contained a lot of business logic. I started
> >thinking, this doesn't make sense. To me, it was more intuitive
> >that the DAO should only be responsible for data access and
> >the business logic and transaction management should be a layer
> >above the DAO. So now, my business objects are responsible for
> >managing the transaction (actually they delegate it to another
> >module) and DAOs "join" the transaction in progress. The DAO
> >become more reusable and are decoupled from the mechanism that
> >manages the transaction. So now I have something like the
> >following:
> >
> >ITransaction trans = // get a transaction object
> >
> >try {
> >
> >trans.begin();
> >
> >dao1.insert(dto);
> >dto2.setForeignKeyId(dto.getIdentity());
> >dto3.setForeignKeyId(dao1.getIdentity());
> >
> >dao2.insert();
> >dao3.insert();
> >
> >
> >} catch (DatastoreException de) {
> >
> >   trans.setRollbackOnly();
> >   throw new BusinessException(de);
> >
> >} finally {
> >
> >  trans.end();
> >
> >}
> >
> >
> >Each DAO joins the transaction (accesses the Connection in the
> same thread)
> >and uses it to perform the necessary data access operation. A nice side
> >effect
> >is that all the tediousness and complexity involved in managing the
> >transaction is
> >wrapped up in a simple API and not over multiple DAOs.
> >
> >Right now, I use straight JDBC but if I decided to use JDO or another
> >mechanism for transactions, my business client doesn't change. Just like
> >if I change my business logic, my web client (Struts Action classes)
> >don't have to change. I find this provides more cohesion within layers.
> >That is, the business objects do business stuff by delegating to
> data access
> >objects and data access objects just access data and tend to deal with
> >tables
> >that are related.
> >
> >This is just one way to do it, as Kevin already mentioned, there
> are other
> >ways to skin this cat.
> >
> >HTH,
> >
> >robert
> >
> >
> >--
> >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: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

Hi Robert,
that is more or less what I am aiming to do. I see you don't pass 
connections around - at least not across your business to DAO interface. 
So from your code snippet, I guess your transaction object gets the 
connection and puts it somewhere that the DAOs can find it? Or do you 
pass your transaction object into your DAOs via their constructors?

I am going with the struts connection pool so I'm thinking how I can 
wrap them up without having to repeat lots of error handling in the 
business objects.

Regards
Adam

Robert Taylor wrote:

>Adam, when I first started using DAO in my application,
>I had course grained DAO's that encapsulated transactions.
>They were responsible for managing the transaction boundries
>(getting the connection, committing or rolling back, and then
>releasing the connection). I then found that they were not
>as reusable and they contained a lot of business logic. I started
>thinking, this doesn't make sense. To me, it was more intuitive
>that the DAO should only be responsible for data access and
>the business logic and transaction management should be a layer
>above the DAO. So now, my business objects are responsible for
>managing the transaction (actually they delegate it to another
>module) and DAOs "join" the transaction in progress. The DAO
>become more reusable and are decoupled from the mechanism that
>manages the transaction. So now I have something like the
>following:
>
>ITransaction trans = // get a transaction object
>
>try {
>
>trans.begin();
>
>dao1.insert(dto);
>dto2.setForeignKeyId(dto.getIdentity());
>dto3.setForeignKeyId(dao1.getIdentity());
>
>dao2.insert();
>dao3.insert();
>
>
>} catch (DatastoreException de) {
>
>   trans.setRollbackOnly();
>   throw new BusinessException(de);
>
>} finally {
>
>  trans.end();
>
>}
>
>
>Each DAO joins the transaction (accesses the Connection in the same thread)
>and uses it to perform the necessary data access operation. A nice side
>effect
>is that all the tediousness and complexity involved in managing the
>transaction is
>wrapped up in a simple API and not over multiple DAOs.
>
>Right now, I use straight JDBC but if I decided to use JDO or another
>mechanism for transactions, my business client doesn't change. Just like
>if I change my business logic, my web client (Struts Action classes)
>don't have to change. I find this provides more cohesion within layers.
>That is, the business objects do business stuff by delegating to data access
>objects and data access objects just access data and tend to deal with
>tables
>that are related.
>
>This is just one way to do it, as Kevin already mentioned, there are other
>ways to skin this cat.
>
>HTH,
>
>robert
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>



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

Re: Design Advice - Relational Databases & Java Objects

[Robert Taylor]

> If the data access objects completely encapsulate
> the connection stuff,
> how does the business object wrap two calls to the
> data access layer in
> one transaction?  Take for example the well-worn
> credit and debit
> financial transaction. Would you wrap that up into
> one data access
> object and say OK, we've got two operations rolled
> into one and we can't
> seperate them and re-use them, but that's necessary
> for a transaction?
>
> On the other hand, if the data access objects are
> handed the connection
> by the business object, or if the connection came
> from the struts
> connection pool, then the transaction could be
> handled easily I know. Am
> I chasing a Holy Grail here?
>

Adam, when I first started using DAO in my application,
I had course grained DAO's that encapsulated transactions.
They were responsible for managing the transaction boundries
(getting the connection, committing or rolling back, and then
releasing the connection). I then found that they were not
as reusable and they contained a lot of business logic. I started
thinking, this doesn't make sense. To me, it was more intuitive
that the DAO should only be responsible for data access and
the business logic and transaction management should be a layer
above the DAO. So now, my business objects are responsible for
managing the transaction (actually they delegate it to another
module) and DAOs "join" the transaction in progress. The DAO
become more reusable and are decoupled from the mechanism that
manages the transaction. So now I have something like the
following:

ITransaction trans = // get a transaction object

try {

trans.begin();

dao1.insert(dto);
dto2.setForeignKeyId(dto.getIdentity());
dto3.setForeignKeyId(dao1.getIdentity());

dao2.insert();
dao3.insert();


} catch (DatastoreException de) {

   trans.setRollbackOnly();
   throw new BusinessException(de);

} finally {

  trans.end();

}


Each DAO joins the transaction (accesses the Connection in the same thread)
and uses it to perform the necessary data access operation. A nice side
effect
is that all the tediousness and complexity involved in managing the
transaction is
wrapped up in a simple API and not over multiple DAOs.

Right now, I use straight JDBC but if I decided to use JDO or another
mechanism for transactions, my business client doesn't change. Just like
if I change my business logic, my web client (Struts Action classes)
don't have to change. I find this provides more cohesion within layers.
That is, the business objects do business stuff by delegating to data access
objects and data access objects just access data and tend to deal with
tables
that are related.

This is just one way to do it, as Kevin already mentioned, there are other
ways to skin this cat.

HTH,

robert


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

Re: Design Advice - Relational Databases & Java Objects

[Kevin . Bedell]

>
>>
>>As mentioned elsewhere, getting a database connection from the web tier
>>is not a good practice. The Struts framework does try to encourage best
>>practice but sometimes takes a dip in the pool of pragmatism. The
>>Generic Connection pool is one example of this. The data access objects
>>should take care of all the connection stuff and just pass back standard
>>Java objects like JavaBeans and Collections. The web tier, and even
>>business tier, does not need to know where the data comes from.
>>

>
>If the data access objects completely encapsulate the connection stuff,
>how does the business object wrap two calls to the data access layer in
>one transaction?  Take for example the well-worn credit and debit
>financial transaction. Would you wrap that up into one data access
>object and say OK, we've got two operations rolled into one and we can't
>seperate them and re-use them, but that's necessary for a transaction?

>
>On the other hand, if the data access objects are handed the connection
>by the business object, or if the connection came from the struts
>connection pool, then the transaction could be handled easily I know. Am
>I chasing a Holy Grail here?


I believe it may be worthwhile to separate transactional considerations
from data access object design. If you need to manage transactions across
multiple database updates, then consolidating all your data access code
into a single DAO is only one way to handle it.

Once you get to the point of needing to manage transactions across multiple
data access objects, it may be worthwile to use an EJB Server (JBoss is
free after all if cost is the issue). Then you can just grab a
UserTransaction to wrap whatever code you want in the web tier and use the
ejb server for managing the transaction details. Then your DAO design
doesn't have to be impacted (as much) by your to manage the transaction.

The other issue is the granularity of the Data Access Object. These can be
fairly coarse-grained and handle updates/transactions across multiple jdbc
connections even in the web tier.

For example, in your example you could have something like:

/*
 * handle the debit/credit transaction
 */

UserAccountDAO ua = new UserAccountDAO(userID);

try {
 ua.beginDAOManagedTx();
 ua.processDebit();
 ua.prcessCredit();
 ua.commitDAOManagedTx();
} catch (DAOApplicationException e) {
 ua.rollbackDAOManagedTx();
}

In this situation the DAO could somehow manually handle the transaction
internally and just throw a DAOApplicationException if problems arise.

I guess what I'm saying is "there ain't no holy grail". All you have is
trade-offs between cost, quality and schedule and you do your best.
Different solutions may be better depending on the project and where you're
at...

As they say in Perl, TIMTOWTDI - there's more that one way to do it...

>
>Adam
>

FWIW -
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: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

>
>
>As mentioned elsewhere, getting a database connection from the web tier
>is not a good practice. The Struts framework does try to encourage best
>practice but sometimes takes a dip in the pool of pragmatism. The
>Generic Connection pool is one example of this. The data access objects
>should take care of all the connection stuff and just pass back standard
>Java objects like JavaBeans and Collections. The web tier, and even
>business tier, does not need to know where the data comes from. 
>  
>
If the data access objects completely encapsulate the connection stuff, 
how does the business object wrap two calls to the data access layer in 
one transaction?  Take for example the well-worn credit and debit 
financial transaction. Would you wrap that up into one data access 
object and say OK, we've got two operations rolled into one and we can't 
seperate them and re-use them, but that's necessary for a transaction?

On the other hand, if the data access objects are handed the connection 
by the business object, or if the connection came from the struts 
connection pool, then the transaction could be handled easily I know. Am 
I chasing a Holy Grail here?

Adam


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

Re: Design Advice - Relational Databases & Java Objects

[Ted Husted]

> (1) Is it best for the data access layer to throw exceptions on error to
> be picked up by the business objects & then struts actions, or would it
> be good to use a struts-type message object and use strings in the
> application resources file (I'm just worried my exceptions' text would
> not be multi-lingual)

In the event of a real emergency, the data access layer should throw
exceptions, which your business layer can catch. I find chaining
exceptions to be very effective. 

http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-exceptions.html

You can add your own business explanationa at the top of the chain and
show both the business explantion and the actual cause. The business
explanation calms the mere mortals and the actual cause helps tech
support with problem determination. 

The Struts message system builds on the standard Java ResourceBundle
framework. So I would say that it is perfectly valid for your business 
objects to return tokens from the ApplicationResource file. This file 
can be used in any application and is not Struts-specific. (Especially 
if you are using the message tags from Struts 1.1b or 1.0 version of 
the Validator.)

If you really want to hedge your bets, write your own business layer
first. This layer takes the input each business operation requires and
hands back a Collection, Object, or maybe just a status code.
Internally, the business layer takes the input and connects to the data
access layer (JDBC, Castor, Turbine, whatever). This can also let you
chain the exceptions or do whatever other handling you need to make.
Your business layer becomes bound to the data access layer but can be
changed without touching the web tier. 

This also makes it easy to use multiple data access devices. You might
need to use Castor for some things and Lucene for others. The business
layer can provide a consistent interface to the application platform
(Struts, Swing, whatever), and then choose whatever source it wants to
use for data. This would also include manufacturing data for testing or
debugging.

Chapter 12 and 13 of Professional JSP Site Design from Wrox show using 
this approach for JDBC and then integrating Lucene for some of the 
searches. Struts is used by the example application here, as it is 
throughout most of the book. 

http://jakarta.apache.org/struts/resources.html#books
(4th from the top)

The Action's role is to bundle the input from the ActionForm bean into
whatever input the business layer expects. The Action then either
forward the result along or cope with any error condition.


> (2) How would I get the database connection info to the data access
> layer? Presuming I want to set it up in struts-config.xml or as in
> commons-dbcp, would I then pass it in from struts actions into the
> business object and then into the data access layer as a parameter on
> each call?


As mentioned elsewhere, getting a database connection from the web tier
is not a good practice. The Struts framework does try to encourage best
practice but sometimes takes a dip in the pool of pragmatism. The
Generic Connection pool is one example of this. The data access objects
should take care of all the connection stuff and just pass back standard
Java objects like JavaBeans and Collections. The web tier, and even
business tier, does not need to know where the data comes from. 

-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services


Adam Hardy wrote:
> 
> Hi All,
> 
> I saw this thread in the archives and I thought I'd pinch the title.
> I've spent this afternoon surfing the web looking at stuff on Sun,
> Jakarta  and lots of smaller sites looking for a ready-made data access
> layer package but I take it there isn't an open-source one out there.
> 
> Obviously I don't want to tie my data access layer to struts, so there
> are a few questions I've got.
> 
> (1) Is it best for the data access layer to throw exceptions on error to
> be picked up by the business objects & then struts actions, or would it
> be good to use a struts-type message object and use strings in the
> application resources file (I'm just worried my exceptions' text would
> not be multi-lingual)
> 
> (2) How would I get the database connection info to the data access
> layer? Presuming I want to set it up in struts-config.xml or as in
> commons-dbcp, would I then pass it in from struts actions into the
> business object and then into the data access layer as a parameter on
> each call?
> 
> I've seen quite a few patterns like www.martinfowler.com and code like
> in Sun's Pet Store, so I think I've got a fairly good idea of what I
> need. The data access layer I want has got to:
> 
> - take as input and return as output Data Transport Objects
> - allow the business objects to control transactions
> - use a connection pool
> - possibly keep the SQL statements in an external XML file
> - have comprehensive error handli

Re: Design Advice - Relational Databases & Java Objects

[@Basebeans.com]

Subject: Re: Design Advice - Relational Databases & Java Objects
From: Vic C <[EMAIL PROTECTED]>
 ===
Somone someplace need to know "how" the DB layer talks to DB. No magic 
in computers, and a common applied practice is roll your own beans.

The beans need to logicaly map to the presentation. For example if you 
have a master detail or more complex relationship on the page, I do this 
using beans that contains beans that iterate that reprsent the logical 
relationship (for example a mutual fund information with a list of 
stocks in it would be a mortgage bean that has a DAO that contains a 
stock bean that iterates and has a stocks DAO based on a foreign key, if 
that is what the user wants to see). But how this logical relationship 
makes sense in your application requires your thinking, therefore no O/R 
tool can do it for you.

In addition, you need to make sure your beans work with other tags, such 
as Standard Tags (you should be using Standard Tags as much as possible) 
or even bean define. Implication here is that if you have MVC simple 
beans you are set. However if you do PetStore type designs, where you 
have BO and VO and DTO... it makes it a bit less flexible.

Most automated tools are only usefull for very simple or very small 
applications.
Just learn JDBC and RowSet and you are set.

my 2 c.
Vic




Jin Bal wrote:
> IMHO
> It's better that any db access layer does not know "how" to get a database
> connection,  it just gets given them by the client calling it.  This way if
> you need to change the way you grab db connections the db access layer is
> none the wiser and no code changes are needed
> 
> Jin
> - Original Message -
> From: "Adam Hardy" <[EMAIL PROTECTED]>
> To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> Sent: Wednesday, May 29, 2002 5:44 PM
> Subject: Design Advice - Relational Databases & Java Objects
> 
> 
> 
>>Hi All,
>>
>>I saw this thread in the archives and I thought I'd pinch the title.
>>I've spent this afternoon surfing the web looking at stuff on Sun,
>>Jakarta  and lots of smaller sites looking for a ready-made data access
>>layer package but I take it there isn't an open-source one out there.
>>
>>Obviously I don't want to tie my data access layer to struts, so there
>>are a few questions I've got.
>>
>>(1) Is it best for the data access layer to throw exceptions on error to
>>be picked up by the business objects & then struts actions, or would it
>>be good to use a struts-type message object and use strings in the
>>application resources file (I'm just worried my exceptions' text would
>>not be multi-lingual)
>>
>>(2) How would I get the database connection info to the data access
>>layer? Presuming I want to set it up in struts-config.xml or as in
>>commons-dbcp, would I then pass it in from struts actions into the
>>business object and then into the data access layer as a parameter on
>>each call?
>>
>>
>>
>>I've seen quite a few patterns like www.martinfowler.com and code like
>>in Sun's Pet Store, so I think I've got a fairly good idea of what I
>>need. The data access layer I want has got to:
>>
>>- take as input and return as output Data Transport Objects
>>- allow the business objects to control transactions
>>- use a connection pool
>>- possibly keep the SQL statements in an external XML file
>>- have comprehensive error handling & reporting
>>
>>
>>
>>
>>--
>>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: Design Advice - Relational Databases & Java Objects

[Steve Muench]

Using the Oracle Business Components for Java J2EE framework, you would:

   (1) Create a "ViewObject" component and paste in what SQL query
   you want to work with (including any bind variables if the
   result you need is parameterized).

   (2) Use the viewobject to get the collection of value objects
   resulting from the query (if you want the actual data, and/or..)
   by invoking its executeQuery() method.

   (3) Call the getEstimatedRowCount() method on the viewobject
   component if you want the framework to do the count for you
   using an underlying (automatically done for you) COUNT(*)
   query.

Not sure how other frameworks do this, but others with experience
in those frameworks will surely chime in...

__
Steve Muench - Developer, Product Mgr, Java/XML Evangelist, Author
Simplify J2EE and EJB Development with BC4J
http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
Building Oracle XML Apps, www.oreilly.com/catalog/orxmlapp
- Original Message - 
From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Friday, May 31, 2002 10:01 AM
Subject: Re: Design Advice - Relational Databases & Java Objects


| There's still one question I've got about using object - relational 
| mapping & DB access packages:
| 
| what happens when I want to pull out a COUNT(*) on a grouping in the 
| database? For instance when I want to show the number of people who've 
| voted on an online survey, or the number of replies to a message in an 
| online forum? How would I integrate that into the framework? Or would it 
| have to be seperate?



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

Re: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

There's still one question I've got about using object - relational 
mapping & DB access packages:

what happens when I want to pull out a COUNT(*) on a grouping in the 
database? For instance when I want to show the number of people who've 
voted on an online survey, or the number of replies to a message in an 
online forum? How would I integrate that into the framework? Or would it 
have to be seperate?

Re the book at http://www.object-relational.com/object-relational.html : 
I didn't get further than the document's table of contents, which is why 
I didn't see that it was a book to purchase - at a cool $1800. That's a 
pity.



[EMAIL PROTECTED] wrote:

>The link that I included in Chapter 6 actually has a 
>cost associated with getting at that information. I 
>believe it's quite severe. What these guys have done is 
>to compare these 13 products from every angle imaginable 
>and they are selling their findings. 
>
>I mentioned that this link is beneficial only if your 
>project had some serious funds and you wanted to be 
>absolutely sure that you were picking the correct 
>implementation.
>
>Unfortunately, applications have different requirements 
>as well as resources available. No one solution is going 
>to be the perfect one for all. I would prefer to buy an 
>ORM solution, rather than building one, although I know 
>that some developers feel the opposite way.
>
>Chuck
>  
>
>>Oh boy, now I've got information overload! Fortunately there's a link in 
>>Chuck Cavaness's book to an article reviewing & comparing some of them - 
>>although strangely they include Forte for Java from Sun instead of JDO. 
>>Well, I can see what I'm going to be doing this weekend.
>>
>>Regards
>>Adam
>>
>>
>>
>>
>>Steve Muench wrote:
>>
>>
>>
>>>Oracle's J2EE Framework "Business Components for Java"
>>>makes it very easy to read and write from collections
>>>of values objects (sourced from the database) with
>>>automatic interaction with business objects that
>>>centralize your business rules, and handles the OR mapping
>>>for your business objects. You pick the "shape" of
>>>the data you need in your view layer, and it implements
>>>all of the handlers for your value object collections
>>>and optionally makes the value objects in these
>>>collections transparently updateable, delegating 
>>>changes back through your business object layer
>>>with no yucky code you have to write yourself.
>>>
>>>A whitepaper on all the capabilities is at:
>>>
>>>http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
>>>
>>>If you've read the O'Reilly Struts book sample chapters
>>>on TheServerSide.com, basically all of the Model Layer things
>>>that Chuck describes in Chapter 6, "Struts Model Components"
>>>as necessary pieces for your working Struts-with-Database-
>>>and-Business-Logic application, the BC4J framework
>>>implements for you. You basically just tell it the
>>>tables you want to work with (for your BO layer), or
>>>forward generate those tables from a BO object model
>>>that you design, and then tell it what queries your
>>>view layer needs to perform.
>>>
>>>You don't need to write model layer plumbing code.
>>>
>>> -> Don't bother writing Value Object classes
>>>
>>> -> Don't bother writing JDBC code for queries
>>>
>>> -> Don't bother writing a class to expose your
>>>collections of value objects to the view layer
>>>
>>>All of these things are done for you.
>>>
>>>Plus, it works with any SQL database, not only Oracle. :-)
>>>
>>>I'm planning a whitepaper that specifically illustrates
>>>how to couple Struts with BC4J next.
>>>
>>>__
>>>Steve Muench - Developer, Product Mgr, Java/XML Evangelist, Author
>>>Simplify J2EE and EJB Development with BC4J
>>>http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
>>>Building Oracle XML Apps, www.oreilly.com/catalog/orxmlapp
>>>- Original Message - 
>>>From: <[EMAIL PROTECTED]>
>>>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>>>Sent: Wednesday, May 29, 2002 6:44 PM
>>>Subject: Re: Design Advice - Relational Databases & Java Objects
>>>
>>>
>>>| 
>>>| 
&g

Re: Design Advice - Relational Databases & Java Objects

[chuckcavaness]

The link that I included in Chapter 6 actually has a 
cost associated with getting at that information. I 
believe it’s quite severe. What these guys have done is 
to compare these 13 products from every angle imaginable 
and they are selling their findings. 

I mentioned that this link is beneficial only if your 
project had some serious funds and you wanted to be 
absolutely sure that you were picking the correct 
implementation.

Unfortunately, applications have different requirements 
as well as resources available. No one solution is going 
to be the perfect one for all. I would prefer to buy an 
ORM solution, rather than building one, although I know 
that some developers feel the opposite way.

Chuck
> Oh boy, now I've got information overload! Fortunately there's a link in 
> Chuck Cavaness's book to an article reviewing & comparing some of them - 
> although strangely they include Forte for Java from Sun instead of JDO. 
> Well, I can see what I'm going to be doing this weekend.
> 
> Regards
> Adam
> 
> 
> 
> 
> Steve Muench wrote:
> 
> >Oracle's J2EE Framework "Business Components for Java"
> >makes it very easy to read and write from collections
> >of values objects (sourced from the database) with
> >automatic interaction with business objects that
> >centralize your business rules, and handles the OR mapping
> >for your business objects. You pick the "shape" of
> >the data you need in your view layer, and it implements
> >all of the handlers for your value object collections
> >and optionally makes the value objects in these
> >collections transparently updateable, delegating 
> >changes back through your business object layer
> >with no yucky code you have to write yourself.
> >
> >A whitepaper on all the capabilities is at:
> >
> >http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
> >
> >If you've read the O'Reilly Struts book sample chapters
> >on TheServerSide.com, basically all of the Model Layer things
> >that Chuck describes in Chapter 6, "Struts Model Components"
> >as necessary pieces for your working Struts-with-Database-
> >and-Business-Logic application, the BC4J framework
> >implements for you. You basically just tell it the
> >tables you want to work with (for your BO layer), or
> >forward generate those tables from a BO object model
> >that you design, and then tell it what queries your
> >view layer needs to perform.
> >
> >You don't need to write model layer plumbing code.
> >
> >  -> Don't bother writing Value Object classes
> >
> >  -> Don't bother writing JDBC code for queries
> >
> >  -> Don't bother writing a class to expose your
> > collections of value objects to the view layer
> >
> >All of these things are done for you.
> >
> >Plus, it works with any SQL database, not only Oracle. :-)
> >
> >I'm planning a whitepaper that specifically illustrates
> >how to couple Struts with BC4J next.
> >
> >__
> >Steve Muench - Developer, Product Mgr, Java/XML Evangelist, Author
> >Simplify J2EE and EJB Development with BC4J
> >http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
> >Building Oracle XML Apps, www.oreilly.com/catalog/orxmlapp
> >- Original Message - 
> >From: <[EMAIL PROTECTED]>
> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >Sent: Wednesday, May 29, 2002 6:44 PM
> >Subject: Re: Design Advice - Relational Databases & Java Objects
> >
> >
> >| 
> >| 
> >| 
> >| Adam -
> >| 
> >| Have you looked at Torque from the Jakarta Tubine project?
> >| 
> >| I haven't used it but have heard good things about it. It provides an
> >| ability to perform O/R mapping using an XML configuration file - and (as I
> >| understand) it creates Java files for you that implement a peristence
> >| layer.
> >| 
> >| FWIW -
> >| Kevin
> >| 
> >| 
> >| 
> >| 
> >| Adam Hardy <[EMAIL PROTECTED]> on 05/29/2002 12:44:28 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:  Design Advice - Relational Databases & Java Objects
> >| 
> >| 
> >| Hi All,
> >| 
> >| I saw this thread in the archives and I thought I'd pinch

Re: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

Oh boy, now I've got information overload! Fortunately there's a link in 
Chuck Cavaness's book to an article reviewing & comparing some of them - 
although strangely they include Forte for Java from Sun instead of JDO. 
Well, I can see what I'm going to be doing this weekend.

Regards
Adam




Steve Muench wrote:

>Oracle's J2EE Framework "Business Components for Java"
>makes it very easy to read and write from collections
>of values objects (sourced from the database) with
>automatic interaction with business objects that
>centralize your business rules, and handles the OR mapping
>for your business objects. You pick the "shape" of
>the data you need in your view layer, and it implements
>all of the handlers for your value object collections
>and optionally makes the value objects in these
>collections transparently updateable, delegating 
>changes back through your business object layer
>with no yucky code you have to write yourself.
>
>A whitepaper on all the capabilities is at:
>
>http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
>
>If you've read the O'Reilly Struts book sample chapters
>on TheServerSide.com, basically all of the Model Layer things
>that Chuck describes in Chapter 6, "Struts Model Components"
>as necessary pieces for your working Struts-with-Database-
>and-Business-Logic application, the BC4J framework
>implements for you. You basically just tell it the
>tables you want to work with (for your BO layer), or
>forward generate those tables from a BO object model
>that you design, and then tell it what queries your
>view layer needs to perform.
>
>You don't need to write model layer plumbing code.
>
>  -> Don't bother writing Value Object classes
>
>  -> Don't bother writing JDBC code for queries
>
>  -> Don't bother writing a class to expose your
> collections of value objects to the view layer
>
>All of these things are done for you.
>
>Plus, it works with any SQL database, not only Oracle. :-)
>
>I'm planning a whitepaper that specifically illustrates
>how to couple Struts with BC4J next.
>
>__
>Steve Muench - Developer, Product Mgr, Java/XML Evangelist, Author
>Simplify J2EE and EJB Development with BC4J
>http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
>Building Oracle XML Apps, www.oreilly.com/catalog/orxmlapp
>- Original Message - 
>From: <[EMAIL PROTECTED]>
>To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>Sent: Wednesday, May 29, 2002 6:44 PM
>Subject: Re: Design Advice - Relational Databases & Java Objects
>
>
>| 
>| 
>| 
>| Adam -
>| 
>| Have you looked at Torque from the Jakarta Tubine project?
>| 
>| I haven't used it but have heard good things about it. It provides an
>| ability to perform O/R mapping using an XML configuration file - and (as I
>| understand) it creates Java files for you that implement a peristence
>| layer.
>| 
>| FWIW -
>| Kevin
>| 
>| 
>| 
>| 
>| Adam Hardy <[EMAIL PROTECTED]> on 05/29/2002 12:44:28 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:  Design Advice - Relational Databases & Java Objects
>| 
>| 
>| Hi All,
>| 
>| I saw this thread in the archives and I thought I'd pinch the title.
>| I've spent this afternoon surfing the web looking at stuff on Sun,
>| Jakarta  and lots of smaller sites looking for a ready-made data access
>| layer package but I take it there isn't an open-source one out there.
>| 
>| Obviously I don't want to tie my data access layer to struts, so there
>| are a few questions I've got.
>| 
>| (1) Is it best for the data access layer to throw exceptions on error to
>| be picked up by the business objects & then struts actions, or would it
>| be good to use a struts-type message object and use strings in the
>| application resources file (I'm just worried my exceptions' text would
>| not be multi-lingual)
>| 
>| (2) How would I get the database connection info to the data access
>| layer? Presuming I want to set it up in struts-config.xml or as in
>| commons-dbcp, would I then pass it in from struts actions into the
>| business object and then into the data access layer as a parameter on
>| each call?
>| 
>| 
>| 
>| I've seen quite a few patterns like www.martinfowler.com and code

Re: Design Advice - Relational Databases & Java Objects

[Michael Mok]

Adam

We choose Castor because it is a more mature implemetation. In fact Castor
is already available prior to Sun releasing the JDO spec. We only tried
Cocobase (excellent product but expensive) and Castor (free and open
source).  We did not evaluate ObjectBridge hence I cannot comment on it.

In response to your query, yes Castor is completely separated from the
STRUTS action. We created 'helper' class to carried out the CRUD logic.

I will illustrate using a pseudo code example
eg in com.consultech.action.MyAction class
 com.consultech.helper.CustomerSrv custsrv = new
com.consultech.helper.CustomerSrv();
 custsrv.getCustRecords();

in com.consultech.helper.CustomerSrv
  getCustRecords(){
  db = castor. getDatabase();
  db.begin();
  // invoke a Object Query to get a list of customers
  db.commit();
  }






Michael Mok
www.teatimej.com

- Original Message -
From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, May 30, 2002 7:06 PM
Subject: Re: Design Advice - Relational Databases & Java Objects


> Michael,
> I missed Sun's JDO as well. Were you involved in the decision to go with
> Castor? If so, can you say why you chose it over Sun's JDO or
ObjectBridge?
>
>
> Adam
>
> > Michael Mok wrote:
> >
> >> Hello
> >>
> >> We are using Castor and have implemented a STRUTS based online
> >> reservation
> >> system using CASTOR as our data access layer. Castor works well as the
> >> functionalities it provides are non intrusive. What I meant is that it
> >> provides a Mapping.xml file which maps your beans to each table (and
> >> even
> >> views) in the database. In this file you define how you want to map
your
> >> beans to the tables, you get to define how you want the object to be
> >> cache
> >> and what columns needs to be validated prior to update. Castor will
> >> generate the required SQL in real time to perform the create, retrieve,
> >> update and delete (CRUD) operations. Castor will also generate the
> >> correct
> >> SQL syntax for Oracle, Sybase, MySQL etc. That way your application
> >> can be
> >> made database independent as Castor generates SQL specifically for the
> >> database which your application is accessing. This works well on a
> >> server
> >> side application as the application is started once and stay resident
> >> (ie
> >> SQLs are only generated when the application starts).
> >>
> >> Castor also provides a Database.xml file which you define how you want
> >> Castor to connect to the database (eg JDBC driver or JNDI or connection
> >> pool)
> >>
> >> I am not selling Castor, but just like to share my experience.
> >>
> >> Michael
> >>
> >>
> >>
> >> -Original Message-
> >> From: Adam Hardy [mailto:[EMAIL PROTECTED]]
> >> Sent: Thursday, 30 May 2002 17:33
> >> To: Struts Users Mailing List
> >> Subject: Re: Design Advice - Relational Databases & Java Objects
> >>
> >>
> >> Hello Jerome,
> >> I'm not sure why I'm so bad at searching the net & not finding things
> >> like this. ObjectBridge has a feature list that blows me away. Are you
> >> using it? Castor also looks interesting.
> >>
> >> Why do you refer me to JBoss & openEJB? I've no experience with EJB,
but
> >> from what I know, I presume you mean that I could use these EJB
> >> containers for their container managed persistence mechanisms - would
> >> they fulfill the requirements of a data access layer?
> >>
> >> Thanks
> >> Adam
> >>
> >>
> >>
> >> Jerome Jacobsen wrote:
> >>
> >>
> >>
> >>> Have you looked at these opensource projects?
> >>>
> >>> JBoss http://www.jboss.org/
> >>> OpenEJB http://www.openejb.org/
> >>> Castor JDO http://castor.exolab.org/
> >>> ObjectRelationalBridge http://objectbridge.sourceforge.net/
> >>>
> >>> As for (1) I would have the business objects throw exceptions.  I
would
> >>>
> >>
> >> have
> >>
> >>
> >>> the Struts Action convert exceptions to ActionErrors or
> >>> ActionMessages as
> >>> appropriate.
> >>>
> >>> As for (2) the answer depends on the capabilities of the data-access
> >>> layer
> >>> you ar

Re: Design Advice - Relational Databases & Java Objects

[Steve Muench]

Oracle's J2EE Framework "Business Components for Java"
makes it very easy to read and write from collections
of values objects (sourced from the database) with
automatic interaction with business objects that
centralize your business rules, and handles the OR mapping
for your business objects. You pick the "shape" of
the data you need in your view layer, and it implements
all of the handlers for your value object collections
and optionally makes the value objects in these
collections transparently updateable, delegating 
changes back through your business object layer
with no yucky code you have to write yourself.

A whitepaper on all the capabilities is at:

http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html

If you've read the O'Reilly Struts book sample chapters
on TheServerSide.com, basically all of the Model Layer things
that Chuck describes in Chapter 6, "Struts Model Components"
as necessary pieces for your working Struts-with-Database-
and-Business-Logic application, the BC4J framework
implements for you. You basically just tell it the
tables you want to work with (for your BO layer), or
forward generate those tables from a BO object model
that you design, and then tell it what queries your
view layer needs to perform.

You don't need to write model layer plumbing code.

  -> Don't bother writing Value Object classes

  -> Don't bother writing JDBC code for queries

  -> Don't bother writing a class to expose your
 collections of value objects to the view layer

All of these things are done for you.

Plus, it works with any SQL database, not only Oracle. :-)

I'm planning a whitepaper that specifically illustrates
how to couple Struts with BC4J next.

__
Steve Muench - Developer, Product Mgr, Java/XML Evangelist, Author
Simplify J2EE and EJB Development with BC4J
http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
Building Oracle XML Apps, www.oreilly.com/catalog/orxmlapp
- Original Message - 
From: <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 6:44 PM
Subject: Re: Design Advice - Relational Databases & Java Objects


| 
| 
| 
| Adam -
| 
| Have you looked at Torque from the Jakarta Tubine project?
| 
| I haven't used it but have heard good things about it. It provides an
| ability to perform O/R mapping using an XML configuration file - and (as I
| understand) it creates Java files for you that implement a peristence
| layer.
| 
| FWIW -
| Kevin
| 
| 
| 
| 
| Adam Hardy <[EMAIL PROTECTED]> on 05/29/2002 12:44:28 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:  Design Advice - Relational Databases & Java Objects
| 
| 
| Hi All,
| 
| I saw this thread in the archives and I thought I'd pinch the title.
| I've spent this afternoon surfing the web looking at stuff on Sun,
| Jakarta  and lots of smaller sites looking for a ready-made data access
| layer package but I take it there isn't an open-source one out there.
| 
| Obviously I don't want to tie my data access layer to struts, so there
| are a few questions I've got.
| 
| (1) Is it best for the data access layer to throw exceptions on error to
| be picked up by the business objects & then struts actions, or would it
| be good to use a struts-type message object and use strings in the
| application resources file (I'm just worried my exceptions' text would
| not be multi-lingual)
| 
| (2) How would I get the database connection info to the data access
| layer? Presuming I want to set it up in struts-config.xml or as in
| commons-dbcp, would I then pass it in from struts actions into the
| business object and then into the data access layer as a parameter on
| each call?
| 
| 
| 
| I've seen quite a few patterns like www.martinfowler.com and code like
| in Sun's Pet Store, so I think I've got a fairly good idea of what I
| need. The data access layer I want has got to:
| 
| - take as input and return as output Data Transport Objects
| - allow the business objects to control transactions
| - use a connection pool
| - possibly keep the SQL statements in an external XML file
| - have comprehensive error handling & reporting
| 
| 
| 
| 
| --
| 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 

Re: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

Michael,
I missed Sun's JDO as well. Were you involved in the decision to go with 
Castor? If so, can you say why you chose it over Sun's JDO or ObjectBridge?


Adam

> Michael Mok wrote:
>
>> Hello
>>
>> We are using Castor and have implemented a STRUTS based online 
>> reservation
>> system using CASTOR as our data access layer. Castor works well as the
>> functionalities it provides are non intrusive. What I meant is that it
>> provides a Mapping.xml file which maps your beans to each table (and 
>> even
>> views) in the database. In this file you define how you want to map your
>> beans to the tables, you get to define how you want the object to be 
>> cache
>> and what columns needs to be validated prior to update. Castor will
>> generate the required SQL in real time to perform the create, retrieve,
>> update and delete (CRUD) operations. Castor will also generate the 
>> correct
>> SQL syntax for Oracle, Sybase, MySQL etc. That way your application 
>> can be
>> made database independent as Castor generates SQL specifically for the
>> database which your application is accessing. This works well on a 
>> server
>> side application as the application is started once and stay resident 
>> (ie
>> SQLs are only generated when the application starts).
>>
>> Castor also provides a Database.xml file which you define how you want
>> Castor to connect to the database (eg JDBC driver or JNDI or connection
>> pool)
>>
>> I am not selling Castor, but just like to share my experience.
>>
>> Michael
>>
>>
>>
>> -Original Message-
>> From: Adam Hardy [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, 30 May 2002 17:33
>> To: Struts Users Mailing List
>> Subject: Re: Design Advice - Relational Databases & Java Objects
>>
>>
>> Hello Jerome,
>> I'm not sure why I'm so bad at searching the net & not finding things
>> like this. ObjectBridge has a feature list that blows me away. Are you
>> using it? Castor also looks interesting.
>>
>> Why do you refer me to JBoss & openEJB? I've no experience with EJB, but
>> from what I know, I presume you mean that I could use these EJB
>> containers for their container managed persistence mechanisms - would
>> they fulfill the requirements of a data access layer?
>>
>> Thanks
>> Adam
>>
>>
>>
>> Jerome Jacobsen wrote:
>>
>>  
>>
>>> Have you looked at these opensource projects?
>>>
>>> JBoss http://www.jboss.org/
>>> OpenEJB http://www.openejb.org/
>>> Castor JDO http://castor.exolab.org/
>>> ObjectRelationalBridge http://objectbridge.sourceforge.net/
>>>
>>> As for (1) I would have the business objects throw exceptions.  I would
>>>   
>>
>> have
>>  
>>
>>> the Struts Action convert exceptions to ActionErrors or 
>>> ActionMessages as
>>> appropriate.
>>>
>>> As for (2) the answer depends on the capabilities of the data-access 
>>> layer
>>> you are using.
>>>
>>> -Original Message-
>>> From: Adam Hardy [mailto:[EMAIL PROTECTED]]
>>> Sent: Wednesday, May 29, 2002 12:44 PM
>>> To: Struts Users Mailing List
>>> Subject: Design Advice - Relational Databases & Java Objects
>>>
>>>
>>> Hi All,
>>>
>>> I saw this thread in the archives and I thought I'd pinch the title.
>>> I've spent this afternoon surfing the web looking at stuff on Sun,
>>> Jakarta  and lots of smaller sites looking for a ready-made data access
>>> layer package but I take it there isn't an open-source one out there.
>>>
>>> Obviously I don't want to tie my data access layer to struts, so there
>>> are a few questions I've got.
>>>
>>> (1) Is it best for the data access layer to throw exceptions on 
>>> error to
>>> be picked up by the business objects & then struts actions, or would it
>>> be good to use a struts-type message object and use strings in the
>>> application resources file (I'm just worried my exceptions' text would
>>> not be multi-lingual)
>>>
>>> (2) How would I get the database connection info to the data access
>>> layer? Presuming I want to set it up in struts-config.xml or as in
>>> commons-dbcp, would I then pass it in from struts actions into the
>>> business object and then into the data access layer as a paramet

Re: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

Hi Michael,

how does Castor integrate with struts? Is it completely seperated from 
the struts actions by your business objects?

I saw the list of castor exceptions and they didn't seem comprehensive, 
but maybe I'm wrong.

Adam



Michael Mok wrote:

>Hello
>
>We are using Castor and have implemented a STRUTS based online reservation
>system using CASTOR as our data access layer. Castor works well as the
>functionalities it provides are non intrusive. What I meant is that it
>provides a Mapping.xml file which maps your beans to each table (and even
>views) in the database. In this file you define how you want to map your
>beans to the tables, you get to define how you want the object to be cache
>and what columns needs to be validated prior to update. Castor will
>generate the required SQL in real time to perform the create, retrieve,
>update and delete (CRUD) operations. Castor will also generate the correct
>SQL syntax for Oracle, Sybase, MySQL etc. That way your application can be
>made database independent as Castor generates SQL specifically for the
>database which your application is accessing. This works well on a server
>side application as the application is started once and stay resident (ie
>SQLs are only generated when the application starts).
>
>Castor also provides a Database.xml file which you define how you want
>Castor to connect to the database (eg JDBC driver or JNDI or connection
>pool)
>
>I am not selling Castor, but just like to share my experience.
>
>Michael
>
>
>
>-Original Message-
>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, 30 May 2002 17:33
>To: Struts Users Mailing List
>Subject: Re: Design Advice - Relational Databases & Java Objects
>
>
>Hello Jerome,
>I'm not sure why I'm so bad at searching the net & not finding things
>like this. ObjectBridge has a feature list that blows me away. Are you
>using it? Castor also looks interesting.
>
>Why do you refer me to JBoss & openEJB? I've no experience with EJB, but
>from what I know, I presume you mean that I could use these EJB
>containers for their container managed persistence mechanisms - would
>they fulfill the requirements of a data access layer?
>
>Thanks
>Adam
>
>
>
>Jerome Jacobsen wrote:
>
>  
>
>>Have you looked at these opensource projects?
>>
>>JBoss http://www.jboss.org/
>>OpenEJB http://www.openejb.org/
>>Castor JDO http://castor.exolab.org/
>>ObjectRelationalBridge http://objectbridge.sourceforge.net/
>>
>>As for (1) I would have the business objects throw exceptions.  I would
>>
>>
>have
>  
>
>>the Struts Action convert exceptions to ActionErrors or ActionMessages as
>>appropriate.
>>
>>As for (2) the answer depends on the capabilities of the data-access layer
>>you are using.
>>
>>-Original Message-
>>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, May 29, 2002 12:44 PM
>>To: Struts Users Mailing List
>>Subject: Design Advice - Relational Databases & Java Objects
>>
>>
>>Hi All,
>>
>>I saw this thread in the archives and I thought I'd pinch the title.
>>I've spent this afternoon surfing the web looking at stuff on Sun,
>>Jakarta  and lots of smaller sites looking for a ready-made data access
>>layer package but I take it there isn't an open-source one out there.
>>
>>Obviously I don't want to tie my data access layer to struts, so there
>>are a few questions I've got.
>>
>>(1) Is it best for the data access layer to throw exceptions on error to
>>be picked up by the business objects & then struts actions, or would it
>>be good to use a struts-type message object and use strings in the
>>application resources file (I'm just worried my exceptions' text would
>>not be multi-lingual)
>>
>>(2) How would I get the database connection info to the data access
>>layer? Presuming I want to set it up in struts-config.xml or as in
>>commons-dbcp, would I then pass it in from struts actions into the
>>business object and then into the data access layer as a parameter on
>>each call?
>>
>>
>>
>>I've seen quite a few patterns like www.martinfowler.com and code like
>>in Sun's Pet Store, so I think I've got a fairly good idea of what I
>>need. The data access layer I want has got to:
>>
>>- take as input and return as output Data Transport Objects
>>- allow the business objects to control transactions
>>- use a connection pool
>>- possibly keep the SQL statements in an external XML file
>

RE: Design Advice - Relational Databases & Java Objects

[Michael Mok]

Hello

We are using Castor and have implemented a STRUTS based online reservation
system using CASTOR as our data access layer. Castor works well as the
functionalities it provides are non intrusive. What I meant is that it
provides a Mapping.xml file which maps your beans to each table (and even
views) in the database. In this file you define how you want to map your
beans to the tables, you get to define how you want the object to be cache
and what columns needs to be validated prior to update. Castor will
generate the required SQL in real time to perform the create, retrieve,
update and delete (CRUD) operations. Castor will also generate the correct
SQL syntax for Oracle, Sybase, MySQL etc. That way your application can be
made database independent as Castor generates SQL specifically for the
database which your application is accessing. This works well on a server
side application as the application is started once and stay resident (ie
SQLs are only generated when the application starts).

Castor also provides a Database.xml file which you define how you want
Castor to connect to the database (eg JDBC driver or JNDI or connection
pool)

I am not selling Castor, but just like to share my experience.

Michael



-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 30 May 2002 17:33
To: Struts Users Mailing List
Subject: Re: Design Advice - Relational Databases & Java Objects


Hello Jerome,
I'm not sure why I'm so bad at searching the net & not finding things
like this. ObjectBridge has a feature list that blows me away. Are you
using it? Castor also looks interesting.

Why do you refer me to JBoss & openEJB? I've no experience with EJB, but
from what I know, I presume you mean that I could use these EJB
containers for their container managed persistence mechanisms - would
they fulfill the requirements of a data access layer?

Thanks
Adam



Jerome Jacobsen wrote:

>Have you looked at these opensource projects?
>
>JBoss http://www.jboss.org/
>OpenEJB http://www.openejb.org/
>Castor JDO http://castor.exolab.org/
>ObjectRelationalBridge http://objectbridge.sourceforge.net/
>
>As for (1) I would have the business objects throw exceptions.  I would
have
>the Struts Action convert exceptions to ActionErrors or ActionMessages as
>appropriate.
>
>As for (2) the answer depends on the capabilities of the data-access layer
>you are using.
>
>-Original Message-
>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, May 29, 2002 12:44 PM
>To: Struts Users Mailing List
>Subject: Design Advice - Relational Databases & Java Objects
>
>
>Hi All,
>
>I saw this thread in the archives and I thought I'd pinch the title.
>I've spent this afternoon surfing the web looking at stuff on Sun,
>Jakarta  and lots of smaller sites looking for a ready-made data access
>layer package but I take it there isn't an open-source one out there.
>
>Obviously I don't want to tie my data access layer to struts, so there
>are a few questions I've got.
>
>(1) Is it best for the data access layer to throw exceptions on error to
>be picked up by the business objects & then struts actions, or would it
>be good to use a struts-type message object and use strings in the
>application resources file (I'm just worried my exceptions' text would
>not be multi-lingual)
>
>(2) How would I get the database connection info to the data access
>layer? Presuming I want to set it up in struts-config.xml or as in
>commons-dbcp, would I then pass it in from struts actions into the
>business object and then into the data access layer as a parameter on
>each call?
>
>
>
>I've seen quite a few patterns like www.martinfowler.com and code like
>in Sun's Pet Store, so I think I've got a fairly good idea of what I
>need. The data access layer I want has got to:
>
>- take as input and return as output Data Transport Objects
>- allow the business objects to control transactions
>- use a connection pool
>- possibly keep the SQL statements in an external XML file
>- have comprehensive error handling & reporting
>
>
>
>
>--
>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: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

Hello Jerome,
I'm not sure why I'm so bad at searching the net & not finding things 
like this. ObjectBridge has a feature list that blows me away. Are you 
using it? Castor also looks interesting.

Why do you refer me to JBoss & openEJB? I've no experience with EJB, but 
from what I know, I presume you mean that I could use these EJB 
containers for their container managed persistence mechanisms - would 
they fulfill the requirements of a data access layer?

Thanks
Adam



Jerome Jacobsen wrote:

>Have you looked at these opensource projects?
>
>JBoss http://www.jboss.org/
>OpenEJB http://www.openejb.org/
>Castor JDO http://castor.exolab.org/
>ObjectRelationalBridge http://objectbridge.sourceforge.net/
>
>As for (1) I would have the business objects throw exceptions.  I would have
>the Struts Action convert exceptions to ActionErrors or ActionMessages as
>appropriate.
>
>As for (2) the answer depends on the capabilities of the data-access layer
>you are using.
>
>-Original Message-
>From: Adam Hardy [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, May 29, 2002 12:44 PM
>To: Struts Users Mailing List
>Subject: Design Advice - Relational Databases & Java Objects
>
>
>Hi All,
>
>I saw this thread in the archives and I thought I'd pinch the title.
>I've spent this afternoon surfing the web looking at stuff on Sun,
>Jakarta  and lots of smaller sites looking for a ready-made data access
>layer package but I take it there isn't an open-source one out there.
>
>Obviously I don't want to tie my data access layer to struts, so there
>are a few questions I've got.
>
>(1) Is it best for the data access layer to throw exceptions on error to
>be picked up by the business objects & then struts actions, or would it
>be good to use a struts-type message object and use strings in the
>application resources file (I'm just worried my exceptions' text would
>not be multi-lingual)
>
>(2) How would I get the database connection info to the data access
>layer? Presuming I want to set it up in struts-config.xml or as in
>commons-dbcp, would I then pass it in from struts actions into the
>business object and then into the data access layer as a parameter on
>each call?
>
>
>
>I've seen quite a few patterns like www.martinfowler.com and code like
>in Sun's Pet Store, so I think I've got a fairly good idea of what I
>need. The data access layer I want has got to:
>
>- take as input and return as output Data Transport Objects
>- allow the business objects to control transactions
>- use a connection pool
>- possibly keep the SQL statements in an external XML file
>- have comprehensive error handling & reporting
>
>
>
>
>--
>To unsubscribe, e-mail:
>
>For additional commands, e-mail:
>
>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>  
>



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

Re: Design Advice - Relational Databases & Java Objects

[Adam Hardy]

Hi Kevin,
from what I can glean from their website, torque implements what Martin 
Fowler calls the Gateway pattern - tables are directly related to 
classes - but I need his DataMapper pattern (where a finder object finds 
the data and a mapper turns it into anything you like).

Adam

[EMAIL PROTECTED] wrote:

>
>Adam -
>
>Have you looked at Torque from the Jakarta Tubine project?
>
>I haven't used it but have heard good things about it. It provides an
>ability to perform O/R mapping using an XML configuration file - and (as I
>understand) it creates Java files for you that implement a peristence
>layer.
>
>FWIW -
>Kevin
>
>
>
>
>Adam Hardy <[EMAIL PROTECTED]> on 05/29/2002 12:44:28 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:  Design Advice - Relational Databases & Java Objects
>
>
>Hi All,
>
>I saw this thread in the archives and I thought I'd pinch the title.
>I've spent this afternoon surfing the web looking at stuff on Sun,
>Jakarta  and lots of smaller sites looking for a ready-made data access
>layer package but I take it there isn't an open-source one out there.
>
>Obviously I don't want to tie my data access layer to struts, so there
>are a few questions I've got.
>
>(1) Is it best for the data access layer to throw exceptions on error to
>be picked up by the business objects & then struts actions, or would it
>be good to use a struts-type message object and use strings in the
>application resources file (I'm just worried my exceptions' text would
>not be multi-lingual)
>
>(2) How would I get the database connection info to the data access
>layer? Presuming I want to set it up in struts-config.xml or as in
>commons-dbcp, would I then pass it in from struts actions into the
>business object and then into the data access layer as a parameter on
>each call?
>
>
>
>I've seen quite a few patterns like www.martinfowler.com and code like
>in Sun's Pet Store, so I think I've got a fairly good idea of what I
>need. The data access layer I want has got to:
>
>- take as input and return as output Data Transport Objects
>- allow the business objects to control transactions
>- use a connection pool
>- possibly keep the SQL statements in an external XML file
>- have comprehensive error handling & reporting
>
>
>
>
>--
>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:   
>For additional commands, e-mail: 
>
>
>  
>



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

RE: Design Advice - Relational Databases & Java Objects

[Jerome Jacobsen]

Have you looked at these opensource projects?

JBoss http://www.jboss.org/
OpenEJB http://www.openejb.org/
Castor JDO http://castor.exolab.org/
ObjectRelationalBridge http://objectbridge.sourceforge.net/

As for (1) I would have the business objects throw exceptions.  I would have
the Struts Action convert exceptions to ActionErrors or ActionMessages as
appropriate.

As for (2) the answer depends on the capabilities of the data-access layer
you are using.

-Original Message-
From: Adam Hardy [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 29, 2002 12:44 PM
To: Struts Users Mailing List
Subject: Design Advice - Relational Databases & Java Objects


Hi All,

I saw this thread in the archives and I thought I'd pinch the title.
I've spent this afternoon surfing the web looking at stuff on Sun,
Jakarta  and lots of smaller sites looking for a ready-made data access
layer package but I take it there isn't an open-source one out there.

Obviously I don't want to tie my data access layer to struts, so there
are a few questions I've got.

(1) Is it best for the data access layer to throw exceptions on error to
be picked up by the business objects & then struts actions, or would it
be good to use a struts-type message object and use strings in the
application resources file (I'm just worried my exceptions' text would
not be multi-lingual)

(2) How would I get the database connection info to the data access
layer? Presuming I want to set it up in struts-config.xml or as in
commons-dbcp, would I then pass it in from struts actions into the
business object and then into the data access layer as a parameter on
each call?



I've seen quite a few patterns like www.martinfowler.com and code like
in Sun's Pet Store, so I think I've got a fairly good idea of what I
need. The data access layer I want has got to:

- take as input and return as output Data Transport Objects
- allow the business objects to control transactions
- use a connection pool
- possibly keep the SQL statements in an external XML file
- have comprehensive error handling & reporting




--
To unsubscribe, e-mail:

For additional commands, e-mail:





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

Re: Design Advice - Relational Databases & Java Objects

[Kevin . Bedell]

Adam -

Have you looked at Torque from the Jakarta Tubine project?

I haven't used it but have heard good things about it. It provides an
ability to perform O/R mapping using an XML configuration file - and (as I
understand) it creates Java files for you that implement a peristence
layer.

FWIW -
Kevin




Adam Hardy <[EMAIL PROTECTED]> on 05/29/2002 12:44:28 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:  Design Advice - Relational Databases & Java Objects


Hi All,

I saw this thread in the archives and I thought I'd pinch the title.
I've spent this afternoon surfing the web looking at stuff on Sun,
Jakarta  and lots of smaller sites looking for a ready-made data access
layer package but I take it there isn't an open-source one out there.

Obviously I don't want to tie my data access layer to struts, so there
are a few questions I've got.

(1) Is it best for the data access layer to throw exceptions on error to
be picked up by the business objects & then struts actions, or would it
be good to use a struts-type message object and use strings in the
application resources file (I'm just worried my exceptions' text would
not be multi-lingual)

(2) How would I get the database connection info to the data access
layer? Presuming I want to set it up in struts-config.xml or as in
commons-dbcp, would I then pass it in from struts actions into the
business object and then into the data access layer as a parameter on
each call?



I've seen quite a few patterns like www.martinfowler.com and code like
in Sun's Pet Store, so I think I've got a fairly good idea of what I
need. The data access layer I want has got to:

- take as input and return as output Data Transport Objects
- allow the business objects to control transactions
- use a connection pool
- possibly keep the SQL statements in an external XML file
- have comprehensive error handling & reporting




--
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:   
For additional commands, e-mail: 

Re: Design Advice - Relational Databases & Java Objects

[Jin Bal]

IMHO
It's better that any db access layer does not know "how" to get a database
connection,  it just gets given them by the client calling it.  This way if
you need to change the way you grab db connections the db access layer is
none the wiser and no code changes are needed

Jin
- Original Message -
From: "Adam Hardy" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 5:44 PM
Subject: Design Advice - Relational Databases & Java Objects


> Hi All,
>
> I saw this thread in the archives and I thought I'd pinch the title.
> I've spent this afternoon surfing the web looking at stuff on Sun,
> Jakarta  and lots of smaller sites looking for a ready-made data access
> layer package but I take it there isn't an open-source one out there.
>
> Obviously I don't want to tie my data access layer to struts, so there
> are a few questions I've got.
>
> (1) Is it best for the data access layer to throw exceptions on error to
> be picked up by the business objects & then struts actions, or would it
> be good to use a struts-type message object and use strings in the
> application resources file (I'm just worried my exceptions' text would
> not be multi-lingual)
>
> (2) How would I get the database connection info to the data access
> layer? Presuming I want to set it up in struts-config.xml or as in
> commons-dbcp, would I then pass it in from struts actions into the
> business object and then into the data access layer as a parameter on
> each call?
>
>
>
> I've seen quite a few patterns like www.martinfowler.com and code like
> in Sun's Pet Store, so I think I've got a fairly good idea of what I
> need. The data access layer I want has got to:
>
> - take as input and return as output Data Transport Objects
> - allow the business objects to control transactions
> - use a connection pool
> - possibly keep the SQL statements in an external XML file
> - have comprehensive error handling & reporting
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>

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

RE: Design Advice - Relational Databases & Java Objects.

[Scott Abel]

We are also using the DAO/buslogic/action tiers as described in
the messages below.  We've been careful to ensure that only
the business logic classes call any DAO methods - never the
Action classes.

For the DAO layer, I've found it easy enough to use jdbc to
write a single query that joins multiple tables into a ResultSet,
then create multiple related objects from that single ResultSet.
For saving the data back to the database I have to pull apart the
objects and save the data with multiple update and/or insert
statements.

This is a "roll-your-own" object-relational mapping.  If you're
interested in commercial products that do object-relational,
they typically map one object to one table, and this can result
in lower performance due to multiple requests to the DB for
each table, rather than a single request that joins the tables
and brings back all the data in one query.

These tools do have their advantages, though.  You don't need to
know anything about SQL, relational databases, transaction
management, and very little about JDBC as they sit on top of JDBC
and do most of the work for you.

Toplink and the JDO reference implementation (formerly JavaBlend,
now included in Forte for Java from Sun) are two examples of
commercial products.  There are also containers from some of the
Object database vendors available that do essentially the same
thing.  Typically all of these products will work with Oracle,
MS SQL Server and Sybase - some will also work with DB2 and other
RDBMS products.

Someone mentioned Torque for Turbine in this thread, I haven't used
it but experimented a little with other Turbine classes briefly and it
seems like a good alternative to commercial products (it is part of apache
jakarta).

follow this for more info on the commercial stuff:
http://www.object-relational.com/object-relational.html

-Original Message-
From: Francisco Hernandez [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 17, 2002 11:38 AM
To: Struts Users Mailing List
Subject: Re: Design Advice - Relational Databases & Java Objects.


excellent explanation, this should be of help to many people and exactly as
I have implemented it in my own apps.


- Original Message -
From: "Robert Taylor" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, April 17, 2002 4:41 AM
Subject: RE: Design Advice - Relational Databases & Java Objects.


> Rob,
>
> Sun's blue prints are an excellent resource to get an idea of how to
handle
> data access via the web tier.
> In general, I use the Struts action classes as proxies to my business
> objects and my business objects serve
> as proxies to my data access objects and I pass data across tiers using
DTO
> (DataTransportObject [use to be ValueObject]).
> In this fashion, I can keep my business logic reusable in say a Java
> Swing client as well as an HTML client.
>
> IMO, I would not access DAO (data access objects) directly in the Struts
> action classes. This means you
> would have to manage transaction boundries (getting JDBC connection or JDO
> PersistanceManager)
> in your web tier where as it would probably be better to isolate
> these details to your business tier.
>
> We don't use EJB, so the general data flow is as follows:
>
> Client ===> Action ===> BusinessObject ===> DataAccessObject(s) ===>
> Database
>
>
> This keeps BusinessObjects resuseable among Action classes and DAO
> objects reusable in BusinessObjects.
> The BusinessObject manages the transaction boundries and the DAO just uses
> the JDBC connection.
> We maintain all SQL as static final Strings in the DAO's. (reduces object
> creation)
> The BusinessObjects and DAO don't maintain any state, so they are
> singletons. (reduces object creation)
>
> So for example if I wanted to retrieve and display a customer list.
>
> 1. Client sends HTTP request
> 2. Struts delegates request to ShowCustomersAction
> 3. ShowCustomersAction delegates to CustomerBO
> 4. CustomerBO starts a transaction
> 5. CustomerBO delegates  to CustomerDAO
> 6. CustomerDAO executes the query and gets results
> 7. CustomerDAO maps results into a collection of CustomerDTO
> (DataTransportObject)
> 8. CustomerDAO returns collection to CustomerBO
> 9. CustomerBO ends transaction
> 10. CustomerBO returns collection to ShowCustomerAction
> 11. ShowCustomersAction places the connection in the HttpServletRequest as
> an attribute
> 12. ShowCustomersAction forwards to showCustomersView (some jsp)
> 13. ShowCustomersView accesses customer collection using a custom tag
> 14. ShowCustomersView renders customer list
>
>
> I'm sure everyone has there own way of accomplishing the use case above,
but
> this is how I have approache

Re: Design Advice - Relational Databases & Java Objects.

[Francisco Hernandez]

excellent explanation, this should be of help to many people and exactly as
I have implemented it in my own apps.


- Original Message -
From: "Robert Taylor" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, April 17, 2002 4:41 AM
Subject: RE: Design Advice - Relational Databases & Java Objects.


> Rob,
>
> Sun's blue prints are an excellent resource to get an idea of how to
handle
> data access via the web tier.
> In general, I use the Struts action classes as proxies to my business
> objects and my business objects serve
> as proxies to my data access objects and I pass data across tiers using
DTO
> (DataTransportObject [use to be ValueObject]).
> In this fashion, I can keep my business logic reusable in say a Java
> Swing client as well as an HTML client.
>
> IMO, I would not access DAO (data access objects) directly in the Struts
> action classes. This means you
> would have to manage transaction boundries (getting JDBC connection or JDO
> PersistanceManager)
> in your web tier where as it would probably be better to isolate
> these details to your business tier.
>
> We don't use EJB, so the general data flow is as follows:
>
> Client ===> Action ===> BusinessObject ===> DataAccessObject(s) ===>
> Database
>
>
> This keeps BusinessObjects resuseable among Action classes and DAO
> objects reusable in BusinessObjects.
> The BusinessObject manages the transaction boundries and the DAO just uses
> the JDBC connection.
> We maintain all SQL as static final Strings in the DAO's. (reduces object
> creation)
> The BusinessObjects and DAO don't maintain any state, so they are
> singletons. (reduces object creation)
>
> So for example if I wanted to retrieve and display a customer list.
>
> 1. Client sends HTTP request
> 2. Struts delegates request to ShowCustomersAction
> 3. ShowCustomersAction delegates to CustomerBO
> 4. CustomerBO starts a transaction
> 5. CustomerBO delegates  to CustomerDAO
> 6. CustomerDAO executes the query and gets results
> 7. CustomerDAO maps results into a collection of CustomerDTO
> (DataTransportObject)
> 8. CustomerDAO returns collection to CustomerBO
> 9. CustomerBO ends transaction
> 10. CustomerBO returns collection to ShowCustomerAction
> 11. ShowCustomersAction places the connection in the HttpServletRequest as
> an attribute
> 12. ShowCustomersAction forwards to showCustomersView (some jsp)
> 13. ShowCustomersView accesses customer collection using a custom tag
> 14. ShowCustomersView renders customer list
>
>
> I'm sure everyone has there own way of accomplishing the use case above,
but
> this is how I have approached it.
>
> HTH,
>
> robert
>
> PS. If we did switch to using EJB, then the BusinessObjects become
> BusinessDelegates to actual EJBs and
> nothing in the web tier has to change and both DAOs and DTOs can be
reused.
>
>
> > -Original Message-
> > From: rob [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 17, 2002 6:31 AM
> > To: [EMAIL PROTECTED]
> > Subject: Design Advice - Relational Databases & Java Objects.
> >
> >
> > I'm hoping that as many people as possible will contribute their
> > own personal
> > experience and methods to this post.
> >
> > I have a relational database that contains information used to
> > build java objects
> > during runtime,  I'm curious about:
> >
> > - In what classes in struts do people typically connect to
> > the database
> > and build java objects from the database.
> > - Do the objects have interfaces which receive database connections
> > and build themselves from the inside out? or do
> > people make the
> > necessary querys for the information and then pass
> > the data to the
> > constructor?
> > - Any other methods or ideas that might aide my goal of elegance
> > (and simplicity).
> >
> > Please be verbose I'm trying to find an elegant way to do it and
> > though I've tried
> > both perhaps someone here can offer some insight.
> >
> > Examples, Explanations all appreciated.
> >
> > Thanks
> >
> >
> > --
> > 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: Design Advice - Relational Databases & Java Objects.

[Sandra Cann]

For a O-R mapping patterns solution that is integrated with Struts, have a
look at the open source Expresso Framework at www.jcorporate.com.


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

RE: Design Advice - Relational Databases & Java Objects.

[Kyle Brown]

Go read the O-R mapping patterns on Martin Fowler's site
http://www.martinfowler.com/isa.  This covers these questions and a whole
lot more...

Kyle

[EMAIL PROTECTED] on 04/17/2002 01:53:22 PM

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

To:[EMAIL PROTECTED]
cc:
Subject:    RE: Design Advice - Relational Databases & Java Objects.



I'm sure you've got many useful replies already, but let me add my two
cents:

I'm using Torque as an Object-Relational persistence mechanism, and am
getting a lot of mileage out of it.  It's *part* of the Jakarta Turbine
project, is easy to use, and works well.  Among other things, it generates
an object model from a data model.  This object model is easily used from
either your Struts Action classes, or possibly from some class(es) your
Action classes delegate to.

Cheers,
David

-Original Message-
From: rob [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 17, 2002 3:31 AM
To: [EMAIL PROTECTED]
Subject: Design Advice - Relational Databases & Java Objects.

I'm hoping that as many people as possible will contribute their own
personal
experience and methods to this post.

I have a relational database that contains information used to build java
objects
during runtime,  I'm curious about:

 - In what classes in struts do people typically connect to the
database
and build java objects from the database.
 - Do the objects have interfaces which receive database connections
and build themselves from the inside out? or do people make the
necessary querys for the information and then pass the data to
the
constructor?
 - Any other methods or ideas that might aide my goal of elegance
(and simplicity).

Please be verbose I'm trying to find an elegant way to do it and though
I've
tried
both perhaps someone here can offer some insight.

Examples, Explanations all appreciated.

Thanks


--
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: Design Advice - Relational Databases & Java Objects.

[David . A . Ventimiglia]

I'm sure you've got many useful replies already, but let me add my two
cents:

I'm using Torque as an Object-Relational persistence mechanism, and am
getting a lot of mileage out of it.  It's *part* of the Jakarta Turbine
project, is easy to use, and works well.  Among other things, it generates
an object model from a data model.  This object model is easily used from
either your Struts Action classes, or possibly from some class(es) your
Action classes delegate to.  

Cheers,
David

-Original Message-
From: rob [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, April 17, 2002 3:31 AM
To: [EMAIL PROTECTED]
Subject: Design Advice - Relational Databases & Java Objects.

I'm hoping that as many people as possible will contribute their own
personal
experience and methods to this post.

I have a relational database that contains information used to build java
objects
during runtime,  I'm curious about:

- In what classes in struts do people typically connect to the
database
and build java objects from the database.
- Do the objects have interfaces which receive database connections
and build themselves from the inside out? or do people make the
necessary querys for the information and then pass the data to
the
constructor?
- Any other methods or ideas that might aide my goal of elegance
(and simplicity).

Please be verbose I'm trying to find an elegant way to do it and though I've
tried
both perhaps someone here can offer some insight.

Examples, Explanations all appreciated.

Thanks


--
To unsubscribe, e-mail:

For additional commands, e-mail:


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