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] Updated: BestPractices
Date Tue, 11 May 2004 14:51:46 GMT
   Date: 2004-05-11T07:51:46
   Editor: 63.80.251.77 <>
   Wiki: DB OJB Wiki
   Page: BestPractices
   URL: http://wiki.apache.org/db-ojb/BestPractices

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -10,44 +10,42 @@
 How do most of you organize your data access layer? 
 
 Specifically
-* Are you building Composite VO/DTOs? (an object that represents data from
+[BR]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?
-
+[BR] Do you build a new DAO for every mapped value object (VO)?
+[BR] Do you pass these VOs to other layers, or do you adapt them to a more generic object
for biz and view purposes?
+[BR] Do you use QueryBySQL or ReportQuery often?
+[BR] Are you using caching?
+[BR] DO you use PB interface?
+[BR] 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'
+[BR]1. isolate View, business, and data access layers so that a change to one wouldn't break
the others
+[BR]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)
+[BR]1. use (modified) reverseDB to generate VOs and repository_user.xml for tables and views
in DB
+[BR]2. modify VOs, and repository_user.xml to reflect our logical mapping of the tables (compositeVOs)
+[BR]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)
+[BR]4. BusinessDelegate objects get handle to DAO through a factory
+[BR]5. BusinessDelegate controls transaction when it needs to
+[BR]6. OJB query and Criteria are wrapped in our QueryVO object so that biz layer doesn't
know about OJB 
+[BR]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)
 
 Misc
-- schema="&schema;" variable is used in repository_user.xml, so that the
+[BR]- 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 
+[BR]- queryBySQL is used for very complicated SQL (we are trying to phase this out as we
learn OJB)
+[BR]- When calling DB stored procedures we use OJB to get sql.connection and the appropriate
schema
+[BR]- We use SequenceManagerNativeImpl to grab DB2 created Identities
+[BR]- Created a conversion Boolean2CharYN (for converting a single char 'Y' or 'N' in DB
to a boolean
+[BR]- 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
-
+[BR]- queryBySQL fails on DB2/websphere 4 when executing the same query twice (we coded a
workaround)
+[BR]- we have a few 1-1 parent child mappings and we want the parent to contain a child
+[BR]- 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


Mime
View raw message