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:52:57 GMT
   Date: 2004-05-11T07:52:57
   Editor: 63.80.251.77 <>
   Wiki: DB OJB Wiki
   Page: BestPractices
   URL: http://wiki.apache.org/db-ojb/BestPractices

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -10,42 +10,42 @@
 How do most of you organize your data access layer? 
 
 Specifically
-[BR]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)
-[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?
+[[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
-[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'
+[[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)
-[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)
+[[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
-[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)
+[[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
-[BR]- 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)
-[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 
+[[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:
-[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
+[[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