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)?
- 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
- 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
- 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
- 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
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
- 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).
- 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.
