Blog Archives

Advantages of a separate DAO layer


With the arrival of ORM most of operations related to DB, like managing connections, transaction management have been abstracted to a certain extent and this has led to many people believe that we can directly call the entitymanager from service layer. I agree that we hardly change persistence layer ( atleast in services, for products its very much can be a valid scenario), But then can we overlook following advantages of DAO layer (All related to DRY)?

  1. Exception handling at a centralized location for all DAO issues -most of time service layer just pass on the failure to client and do not take any action. DAO can logg the exception, for example hibernate exception, log the query -these all can help dig the issue, and throw a runtime exception which will keep service layer code cleaner
  2. What if same query is being called from multiple location -even inside same service, for example “get list of all students”. A change in in this query, lets say an additional criteria, will have to be tracked across all occurence . If there is DAO, it will be delegated there and changes wil be at single place
  3. A well designed DAO layer can be used across projects -for example recently I wrote a DAO for JCR queries, and most of its part as create node, create heirarchical node, delete node etc were exposed in a manner that the lib was used across project
  4. We might not change the DB, but may be ORM itself need to be changed -for example one of client code which needed a deployment on Google apps had to change from hibernate to JPA (Google apps support JPA but not hibernate) -having a separate DAO made life simpler
  5. On flip side, this does introduce more layers and extra level of delegation, but I feel it’s worth it.

Leveraging factory pattern for UI components in Flex


Using Factory method for UI components is always a good Idea. This helps adding common look/feel, validation etc. to a set of similar component at centralized place.
For example:

  • Text box for price input with custom requirement (as only two decimal places, in a given range, a custom look and feel etc.) can appear on multiple pages
  • Standard stuff as email entry boxes can have similar custom requirement

There are two approaches to deal with above

  1. One argument that most of validation is standard and out of box these day (Email, Date) while css and styling can be leveraged from a shared location, so these can be done “in place”. But greatest flip side I see that any change, say decimal precision from 2 places to 3, color change, background image change etc., will have to be tracked at multiple pages, even if just a reference change (CSS name, Validator name etc).
  2. Factory approach -I can have a method as
    UIElement getATextBoxWith2PlaceDecimal(){
    }
    

    This can encapsulate all validation and custom requirements.

I tend to use factory If I see repeatation on lot of pages -it seems to be a cleaner and maintainable approach.