db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ojb-...@db.apache.org
Subject [DB OJB Wiki] New: BestPractices
Date Tue, 11 May 2004 10:14:05 GMT
   Date: 2004-05-11T03:14:04
   Editor: <>
   Wiki: DB OJB Wiki
   Page: BestPractices
   URL: http://wiki.apache.org/db-ojb/BestPractices

   no comment

New Page:

John G. McCaffrey started the following discussion:

I would like to know how other teams are using OJB, what their experiences
have been, and some of the architecture decisions you have built around OJB.
(I know this is not a pure OJB question, but I would like to help compile a
list of common architecture approaches to help new people get started)

Think of it as a "Here's how my team uses OJB" thread

How do most of you organize your data access layer? 

Are you building Composite VO/DTOs? (an object that represents data from
several tables)
Do you build a new DAO for every mapped value object (VO)?
Do you pass these VOs to other layers, or do you adapt them to a more
generic object for biz and view purposes?
Do you use QueryBySQL or ReportQuery often?
Are you using caching?
DO you use PB interface?
How do you manage Transactions?

Here's how my team uses OJB (RC5)

We had two basic goals when building our architecture
1. isolate View, business, and data access layers so that a change to one
wouldn't break the others
2. isolate OJB, so that the data access layer could be 'swappable'

Steps we take when building on new functionality (we use PB interface)
1. use (modified) reverseDB to generate VOs and repository_user.xml for
tables and views in DB
2. modify VOs, and repository_user.xml to reflect our logical mapping of the
tables (compositeVOs)
3. verify basic CRUD for VO(BaseDAO handles Create, update, insert,
findByVO, findbyPK for any mapped object)
 (optional) build specific DAO if BaseDAO isn't good enough
4. BusinessDelegate objects get handle to DAO through a factory
5. BusinessDelegate controls transaction when it needs to
6. OJB query and Criteria are wrapped in our QueryVO object so that biz
layer doesn't know about OJB 
7. VOs are adapted to view specific objects and passed to struts action
classes (this is to separate the table based VO from the front-end view)

- schema="&schema;" variable is used in repository_user.xml, so that the
application can be migrated from test to production (servlet loads different
repository.xml in each environment)
- queryBySQL is used for very complicated SQL (we are trying to phase this
out as we learn OJB)
- When calling DB stored procedures we use OJB to get sql.connection and the
appropriate schema
- We use SequenceManagerNativeImpl to grab DB2 created Identities
- Created a conversion Boolean2CharYN (for converting a single char 'Y' or
'N' in DB to a boolean
- We had to create our own PlatformCustDb2Impl because the identity query(in
RC5) did work with DB2 7.x 

open issues:
- queryBySQL fails on DB2/websphere 4 when executing the same query twice
(we coded a workaround)
- we have a few 1-1 parent child mappings and we want the parent to contain
a child
- we keep history in our tables, so we often have a date as a primary key,
but we don't know the exact date when we do a join, but we want to join on
the most current date. this is a problem for 1-1

To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message