using O/R mapping tools

[Kevin Viet <vi...@activia.net>]

I know that a lot of threads about O/R mappings but I've got a design
question please answer me.
The O/R mapping defines the persistent layer in the application, most of
time users talk about using J2EE design pattern : DAO. 
What I have understood about DAO is that we define one DAO for one bean 
( XXXBean => XXXDao) is this right ?
But my very question is : is there an another pattern to access the
persistent layer in struts-based application, for example inside an
action or something else !!! ... 

thanks in advance




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: using O/R mapping tools

[Eddie Bush <ek...@swbell.net>]

SimpleORM looks neat, but OJB (http://jakarta.apache.org/ojb) is much 
less obtrusive.  If you're ok with being (very!) tightly coupled to a 
persistence framework, SimpleORM might be ok.  I think OJB is much less 
intrusive though, and - should the decision be handed down to change 
persistence framwork implementations - would be much easier to 
erradicate from the system.  OJB is centered on current standards.  It 
provides a low-level API (PersistenceBroker API) which is a basic 
"persistence kernel" - not as feature-rich as the higher-level APIs, but 
very solid - and also implementations for higher-level APIs such as ODMG 
and JDO.  The ODMG implementation is the current "best practice" for 
OJB; the JDO implementation is still in "prototype state".

<standing-on-soap-box>
OJB doesn't make you extend anything; nor do you have to implement any 
special interfaces*.  You do have to create a mapping (XML) to tell OJB 
what your structure is and how it should obtain/persist objects.  Beyond 
that, you simply "ask OJB for objects", which it will happily retrieve 
for you, and "give OJB objects", which it will happily persist for you. 
 You operate with your classes (getting/setting values) in a very 
object-oriented way -- call your getters and setters!  I really like the 
approach Thomas has taken in designing OJB.  Yes, there are (as with 
*any* project) areas where it could be improved.

I found the initial learning curve to be rather steep.  I blame this on 
my using an outdated version of my JDBC driver.  It "seemed hard" at 
first simply because of that.  In reality, had I built my JDBC driver 
out of CVS before I started, I expect I would have had a very 
rudimentary (one table/class mapped and persisting correctly) 
implementation going with OJB in (at the most) a day (I think such an 
example would be implemented easily in maybe 2 hours, to be honest). 
 From there it's only a matter of learning how you must denote things in 
your mapping file, and learning a couple of additional pecuilarities 
that must be implemented in your database/classes -- none of which 
(IMHO) bring OJB's "obtrusiveness level" up to that of something like 
SimpleORM.  OJB has emerging tools to help you with the mapping process 
too ...
</standing-on-soap-box>

A lot of people ask how OJB compares to something like Castor.  Well 
Castor JDO is supposed to be great.  However, if you ask that question 
on the ojb-user list, you'll find that the most-talented (these are 
someone elses words, and I don't remember who they belong to) Castor JDO 
developers have changed to being OJB JDO developers :-)  I think that 
says a lot right there.

*  Look at your choices
*  Learn what your contract with the framework will be (what must I do? 
 what does it do?  what does it not do?  what must I not do?)
*  Decide what your constraints are (ex.  I don't care what the 
implementation is; it will never change - give me the easiest solution! 
 or  I really want something that will be easily exchanged.  or  I want 
something that supports current best-practice standards.)
*  Make an informed decision based on your constraints and the contracts 
required

Peace,

Eddie

*You may have to implement an OJB interface if you want to have the 
ability to write "trigger-like" code for your classes.

Claudio Parnenzini wrote:

>Personally I don't like DAO. There is not a clear separation between the
>business layer and the persistence layer. In my design, the business
>contains only business/logic code and the persistence layer do an 1:1
>mapping to the database ( You could use EJB, OJB or SimpleORM, etc... to
>make this mapping easily ).
>
>My persistence layer receive a business data object ( ValueObject) that
>store into the DB the values using a Domain persistent object.
>
>To be more clear, here is what happen.
>
>Action -> Copy Form values to the The BusinessDataObject and send it to the
>business
>Business layer -> Do the logic business, create a domain data object and
>send it to the persistence layer.
>Persistence layer -> A domain persistence object store into the database the
>domain object received from the business layer. The domain persistence
>object use 1:1 mapping object to store data into DB ( Use SimpleORM to do
>that, is quite easy to use and have really good performance ).
>
>
>Regards
>
>
>-----Message d'origine-----
>De : Kevin Viet [mailto:vietk@activia.net]
>Envoyé : Friday, August 23, 2002 10:44 AM
>À : struts-user@jakarta.apache.org
>Objet : using O/R mapping tools
>
>
>
>
>I know that a lot of threads about O/R mappings but I've got a design
>question please answer me.
>The O/R mapping defines the persistent layer in the application, most of
>time users talk about using J2EE design pattern : DAO.
>What I have understood about DAO is that we define one DAO for one bean
>( XXXBean => XXXDao) is this right ?
>But my very question is : is there an another pattern to access the
>persistent layer in struts-based application, for example inside an
>action or something else !!! ...
>
>thanks in advance
>
>
>
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: using O/R mapping tools

[Claudio Parnenzini <cp...@sqli.com>]

Personally I don't like DAO. There is not a clear separation between the
business layer and the persistence layer. In my design, the business
contains only business/logic code and the persistence layer do an 1:1
mapping to the database ( You could use EJB, OJB or SimpleORM, etc... to
make this mapping easily ).

My persistence layer receive a business data object ( ValueObject) that
store into the DB the values using a Domain persistent object.

To be more clear, here is what happen.

Action -> Copy Form values to the The BusinessDataObject and send it to the
business
Business layer -> Do the logic business, create a domain data object and
send it to the persistence layer.
Persistence layer -> A domain persistence object store into the database the
domain object received from the business layer. The domain persistence
object use 1:1 mapping object to store data into DB ( Use SimpleORM to do
that, is quite easy to use and have really good performance ).


Regards


-----Message d'origine-----
De : Kevin Viet [mailto:vietk@activia.net]
Envoyé : Friday, August 23, 2002 10:44 AM
À : struts-user@jakarta.apache.org
Objet : using O/R mapping tools




I know that a lot of threads about O/R mappings but I've got a design
question please answer me.
The O/R mapping defines the persistent layer in the application, most of
time users talk about using J2EE design pattern : DAO.
What I have understood about DAO is that we define one DAO for one bean
( XXXBean => XXXDao) is this right ?
But my very question is : is there an another pattern to access the
persistent layer in struts-based application, for example inside an
action or something else !!! ...

thanks in advance




--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>