Example of the power of DAO pattern

Published 5 years, 11 months ago

It’s nice to see your discipline pay off every once in a while. Up until recently all the DAOs I had ever created were simple interfaces to a single query or table. Just recently we encountered an issue that led us to do something a bit more complex.

One of our companies recently implemented a new ERP system. As part of the conversion they decided to only convert open AR invoices. On the surface this was OK with us because we only display open invoices to our customers. However, they actually only converted open balances. The converted invoices had one dummy line, with a dummy description and the remaining outstanding amount for the invoice. So we had a problem. We could see the correct open balance, but if we wanted to see any invoice details (and they always do) we needed to reach back to the old database and pull the data from there.

So we created a small wrapper class around two of our existing DAO classes (one for the new database and one for the old database).

public class MidAtlInvoiceDetailQuery implements DAO {

/** Allied DAO (Old) */
private OracleInvoiceDetailQuery alliedOracleQuery = null;

/** Oracle Order Management DAO (New) */
private MidAtlOracleInvoiceDetailQuery midAtlOracleQuery = null;

/**
* Initializes all of the private DAOs
*/
public MidAtlInvoiceDetailQuery(String datasource) throws Exception {
alliedOracleQuery = new OracleInvoiceDetailQuery("AlliedOracleDS");
midAtlOracleQuery = new MidAtlOracleInvoiceDetailQuery("MidAtlOracleDS");
}

This wrapper class implementes our DAO interface and, for almost all of the methods, just passed it’s parameters into the corresponding method of the actual DAOs.

public void mapParameters(Map map){
  alliedOracleQuery.mapParameters(map);
  midAtlOracleQuery.mapParameters(map);
}

In the list method our wrapper DAO simply calls the list method on the DAO for the new database and examines the result to see if it’s a conversion invoice. If it’s a regular invoice then it just returns the list. If it’s a conversion invoice it calls the list method on the DAO for the old database and returns what it finds there. No big deal, right?

public List list() throws DAOException {
List consolList = new ArrayList();
List midAtlOraList = midAtlOracleQuery.list();

// First check to see if the Invoice is a
// conversion invoice (but only for allied invoices).
// If it is, we need to query allied for the details of the invoice
if (midAtlOraList.size() > 0) {
MidAtlInvoiceDetail invoice = (MidAtlInvoiceDetail) midAtlOraList.get(0);
if ("CONVERSION".equals(invoice.getSource()) &&
"GA".equals(invoice.getConversionSource())) {
List alliedOraList = alliedOracleQuery.list();
consolList.addAll(alliedOraList);
} else if (!"CONVERSION".equals(invoice.getSource())) {
// Just a regular invoice so put it in the list to return
consolList.addAll(midAtlOraList);
}
}

return consolList;
}

So, update this company’s configuration to use the new wrapper DAO, restart the app, and it just works! The application doesn’t know, or care, how the DAO is retrieving it’s data.

It’s one of those things. You know using well established patterns is a good idea, but it takes time to run into the situations where it really pays off.

Category: Java | Tags: