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
- Set Auto-commit ="2" because DB2 doesn't like nested commits

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 mappings

BestPractices (last edited 2009-09-20 22:56:20 by localhost)