What should be the best way to design a DAO class ?
Approach#1: Design DAO class as an object.
class Customer { //customer class } class CustomerDAO { public void saveCustomer(Customer customer) { //code } public Customer getCustomer(int id) { //code } } //Client code class client { public static void main(String[] args) { CustomerDAO customerDAO = new CustomerDAO(); Customer customer = new Customer(); customerDAO.saveCustomer(customer); } }
Approach#2: Design DAO class with static methods (aka static class)
class Customer { //customer class } class CustomerDAO { public static void saveCustomer(Customer customer) { //code } public static Customer getCustomer(int id) { //code } } //Client code class client { public static void main(String[] args) { Customer customer = new Customer(); CustomerDAO.saveCustomer(customer); } }
In approach#1, I have to create an object of DAO class in all the client code (other option is to pass the reference of DAO all around). while in approach#2, I do not have to create the object and the static methods can be designed with no state tracking.
So which approach is the best in design of DAO classes ?
DAO Design Pattern is used to separate the data persistence logic in a separate layer. This way, the service remains completely in dark about how the low-level operations to access the database is done. This is known as the principle of Separation of Logic.
Benefits of using DAO design pattern. DAO design pattern also keeps coupling low between different parts of an application. By using DAO design pattern your View Layer is completely independent of DAO layer and only Service layer has the dependency on it which is also abstracted by using DAO interface.
Accessing a database with a DAO. A Data Access Object class can provide access to a particular data resource without coupling the resource's API to the business logic. For example, sample application classes access catalog categories, products, and items using DAO interface .
ORM and DAO are orthogonal concepts. One has to do with how objects are mapped to database tables, the other is a design pattern for writing objects that access data. You don't choose 'between' them. You can have ORM and DAO is the same application, just as you don't need ORM to use the DAO pattern.
I would recommend approach #1, but would use Spring for dependency injection rather than instantiating DAOs directly.
This way, for unit testing the client code, you can substitue mock DAOs, and verify that the correct DAOs are invoked with the appropriate arguments. (Mockito is useful here.)
If you use static methods, then unit testing is much more difficult, since static methods cannot be overridden.
To have more abstraction :
interface IDAO<T> { public save(T t); public T getById(int id); //...etc }
then
public CustomerDao implements IDAO<Customer>{ public save(Customer c){ //Code here } public Customer getById(int id){ //Code here } }
and DAO tO another domain
public UniversityDao implements IDAO<University>{ public save(University u){ //Code here } public University getById(int id){ //Code here } }
Now the presentation layer or the main Class will contain the code like this :
IDAO dao; dao=new CustomerDao(); //... dao=new UniversityDao();
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With