|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 5
<dao-factory factoryClass="MyDaoFactory">
<property name="property1" value="value1" />
<property name="property2" value="value2" />
</dao-factory>
The getInstance() method uses the org.apache.commons.digester.Digester class (see "Sidebar 1: Apache Software Foundation's Digester Class") to parse the XML configuration file as follows:
private static final String CONFIG_FILE_NAME = "DaoFactory.xml";
private static DaoFactory m_Instance;
public synchronized static final DaoFactory getInstance() throws DaoException
{
final Category category = Category.getInstance(
DaoFactory.class );
if( m_Instance == null )
{
try
{
final Digester digester = new Digester();
digester.addObjectCreate( "dao-factory", null,
"factoryClass" );
digester.addSetProperty( "dao-factory/property",
"name", "value");
m_Instance = ( DaoFactory )digester.parse(
DaoFactory.class.getClassLoader().getResource( CONFIG_FILE_NAME ).toString()
);
}
catch( SAXException sax )
{
throw new DaoException( "Unable to parse configuration
document.", sax );
}
catch( IOException io )
{
throw new DaoException( "Unable to parse configuration
document.", io );
}
}
return m_Instance;
}
Business objects should always use the getInstance() method to obtain a reference to a DaoFactory object, as the method lets you substitute different DaoFactory implementations as needed without changing the business object code. This dynamic instantiation and initialization mechanism
requires that DaoFactory subclasses provide a no-argument, default constructor and should conform to the property setter method naming conventions
described in the JavaBeans 1.0.1 specification.
As you can see, the new Dao interface implements the CRUD (create, retrieve, update, and delete) design pattern. The persistence modifying methods, create(), update(), and delete(), now accept generic Object parameters, as opposed to Customer or Account parameters.
A Dao object represents one connection to the data source, similar to a java.sql.Connection, and should be treated as such. Business objects should adhere to the following guidelines when interacting with Dao objects:
Dao objects. Each time a business object requires a Dao object, it should allow the DaoFactory to create one for it.
Dao objects are not thread-safe. Do not use them in multiple threads.
close() method on the Dao object, as it may release valuable system resources; for example, by closing database connections or JNDI (Java Naming and
Directory Interface) contexts.
Dao object should follow the JavaBeans specification with respect to providing an accessible default constructor and naming property
setter and getter methods.
To maintain data source independence via this framework, however, we must establish a new data source-independent query syntax
for the Dao interface's retrieve() method to use. The Enterprise JavaBeans (EJB) 2.0 specification addresses exactly the same issue via the EJB query language
(EJBQL), providing a simple syntax definition closely resembling SQL (as most EJB vendors use relational databases for container-managed
persistence). However, EJBQL, as specified in EJB 2.0, remains somewhat limited and does not provide an adequate model for
the DAO query language (DAOQL). Although DAOQL's definition is beyond the scope of this article, it should meet these requirements: