When working with Spring and I Hibernate I often travel along the following loop:
1) Create an Entity Class (with jpa annotations)
2) Create Dao class (will extend some generic dao to inherit common functionality, like save, get)
3) Define a service interface to access the dao with an MVC controller (and to use proxy based method calling)
4) Create an implementation for the service
Now this setup creates quite a lot of unnecessary work. Say I add a method to a dao. I also have to
add a method to the service interface and service implementation so it can be called from the app code. This usually leads to the service layer being nothing more than a way to redirect calls to the dao. Furthermore most daos will just have a single custom method and inherit most of the methods from it's generic parent. The 3 tier architecture is useful for providing flexibility, but it creates too many shallow classes.
Heres a technique which has the flexibility of the 3 tier architecture, and also drastically reduces the number of shallow dao classes. The classes in this set up are:
1) The Db class (The Generic Dao )
2) DbCallback (An interface to to provide callback functionality (similar hibernate's callback), the current session will be passed as the first argument.
First the db class
Some examples, db is an instance of Db.class injected by spring
db.executeCallback() will call the execute method in Db.Callback interface, passing in an open session, allowing the class to use the session.
Move code that used to be in the dao to the service layer. Instead of having shalow service layers. The DAO (disc/db access object) pattern no longer applies, since hibernate is an orm which handles that.
Heres a quick example to show how annotations can be used as join points in AOP. The code below simply times the execution of any method wit...
In many database driven applications it can be useful to automate the testing of SQL against a real database. However setting up and maintai...
This post outlines the usages of datalakes and data warehouses. Source: https://www.kdnuggets.com/2015/09/data-lake-vs-data-warehouse...